Comments on: repository design – branch vs tag http://blog.technostoic.net/2009/09/03/repository-design-branch-vs-tag/ Dave Null is my close friend Thu, 17 Nov 2011 16:34:14 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: admin http://blog.technostoic.net/2009/09/03/repository-design-branch-vs-tag/comment-page-1/#comment-444 admin Fri, 04 Sep 2009 09:06:44 +0000 http://blog.technostoic.net/?p=343#comment-444 Pai noi avem oricum diverse branchuri locale in care mai testam stuff (eu unul imi tin totul intr-un git local si vorbesc cu main repo via git-svn), dar ideea de la care am plecat era ca in trunk commiteaza diversi insi si parca n-as face release direct de acolo fara macar o inspectie ochiometrica ca e ok. Dar nici nu vreau ca procedura asta de inspectie sa devina foarte complicata gen pull+merge din toate branchurile, etc. Daca era totul git ar fi fost ceva mai simplu :) dar nu e foarte simplu sa-i convertesc pe toti la git si mai sunt si niste probleme (gen partial checkouts etc), ma rog. Aseara cand ma flame-uiam cu Lorin pe tema asta am produs urmatoarea diagrama: http://ratiu.info/svn.svg (stiu ca e urata si probabil o sa dispara de acolo in cateva zile). Ideea ar fi ca tagul (sau ce-o fi) de production sa pointeze mereu la o versiune recenta de trunk (eventual sa fac cumva niste acl-uri sau commit hooks care sa asigure asta), in timp ce lumea (plus scripturi automate) imping in svn chestii direct in trunk (relativ sane ca sa nu stau prea mult la repo cleanup daca vreau sa fac release rapid la ceva). El nu era foarte de acord cu tag-ul "flotant", intre timp s-a dat batut (hate), dar eu inca nu-s foarte convins ca asa e bine, de-aia pun intrebari filozofice pe care nu le citeste nimeni inafara de tine :) Pai noi avem oricum diverse branchuri locale in care mai testam stuff (eu unul imi tin totul intr-un git local si vorbesc cu main repo via git-svn), dar ideea de la care am plecat era ca in trunk commiteaza diversi insi si parca n-as face release direct de acolo fara macar o inspectie ochiometrica ca e ok. Dar nici nu vreau ca procedura asta de inspectie sa devina foarte complicata gen pull+merge din toate branchurile, etc. Daca era totul git ar fi fost ceva mai simplu :) dar nu e foarte simplu sa-i convertesc pe toti la git si mai sunt si niste probleme (gen partial checkouts etc), ma rog.

Aseara cand ma flame-uiam cu Lorin pe tema asta am produs urmatoarea diagrama: http://ratiu.info/svn.svg (stiu ca e urata si probabil o sa dispara de acolo in cateva zile). Ideea ar fi ca tagul (sau ce-o fi) de production sa pointeze mereu la o versiune recenta de trunk (eventual sa fac cumva niste acl-uri sau commit hooks care sa asigure asta), in timp ce lumea (plus scripturi automate) imping in svn chestii direct in trunk (relativ sane ca sa nu stau prea mult la repo cleanup daca vreau sa fac release rapid la ceva). El nu era foarte de acord cu tag-ul “flotant”, intre timp s-a dat batut (hate), dar eu inca nu-s foarte convins ca asa e bine, de-aia pun intrebari filozofice pe care nu le citeste nimeni inafara de tine :)

]]> By: Liviu http://blog.technostoic.net/2009/09/03/repository-design-branch-vs-tag/comment-page-1/#comment-443 Liviu Fri, 04 Sep 2009 07:41:54 +0000 http://blog.technostoic.net/?p=343#comment-443 De ce totusi sari peste ideea "in svn tags si branches sunt o conventie care dedesubt arata la fel". Mi se pare important sa ti cont de ea. SVN iti ofera libertatea asta (comparativ cu CVS de exemplu), de ce sa o ignori. Eu acum lucrez asa, poate ti se potriveste si tie: fac un "branch" (copie a head-ului) de fiecare data cind modific ceva. Cind e gata (dezvoltare, testare si review) fac merge in head. Codul se pune in production din head. Ai zis si tu "bitii de trunk sunt ganditi sa ajunga in production si ca in production ajung doar biti de trunk". Chiar si trunk e conventie, nu? Daca in cazul filelor de conf e cam pierdere de timp sa tot faci copie la head si apoi merge, poti sa ai copia ta pe care lucrezi. Cind modificarile sunt stabile le faci merge in head. Din cind in cind (eventual, inainte de commiturile tale) faci merge la modificarile altora din head in copia in care lucrezi tu. Deci o sa ai o copie ("branch") per sysadmin pentru modificarile mici si frecvente. De ce totusi sari peste ideea “in svn tags si branches sunt o conventie care dedesubt arata la fel”. Mi se pare important sa ti cont de ea. SVN iti ofera libertatea asta (comparativ cu CVS de exemplu), de ce sa o ignori.
Eu acum lucrez asa, poate ti se potriveste si tie: fac un “branch” (copie a head-ului) de fiecare data cind modific ceva. Cind e gata (dezvoltare, testare si review) fac merge in head. Codul se pune in production din head. Ai zis si tu “bitii de trunk sunt ganditi sa ajunga in production si ca in production ajung doar biti de trunk”. Chiar si trunk e conventie, nu?
Daca in cazul filelor de conf e cam pierdere de timp sa tot faci copie la head si apoi merge, poti sa ai copia ta pe care lucrezi. Cind modificarile sunt stabile le faci merge in head. Din cind in cind (eventual, inainte de commiturile tale) faci merge la modificarile altora din head in copia in care lucrezi tu. Deci o sa ai o copie (“branch”) per sysadmin pentru modificarile mici si frecvente.

]]>