repository design – branch vs tag
Fiind in mare proces creativ cu redesignul repo-ului de SVN, avem o mare dilema pe care ne tot flamam: sa folosim branch sau tag pentru versiunea de productie?
Mai intai situatia: avem o gramada de fisiere si configuri samd pe care le tinem in SVN ca Asa E Bine(TM). E destul de obvious ca vrem sa facem mereu commituri in trunk, e relativ obvious ca nu vrem sa facem release automat pe servere direct din trunk ci de undeva dintr-un branch-sau-tag numit 'production' in care sa ajunga bitii aia doar dupa ce i-a verificat cineva.
Anumita parte a presei, adica eu, e de parere sa folosim un tag care e mereu nitel in urma head-ului de trunk. Aka. aia mici commiteaza chestii in trunk, iar cineva cu mai multa atentie verifica diferentele fata de actualul tag si avanseaza tagul.
Alta parte a presei zice ca tagurile sunt frozen in timp si ca trebuie musai sa faci unul nou si ca e mai bine sa ai un branch in care faci merge.
Sarind peste faptul ca in svn tags si branches sunt o conventie care dedesubt arata la fel, dilema e valida. Parerea mea este ca bitii de trunk sunt ganditi sa ajunga in production si ca in production ajung doar biti de trunk. De asemenea, nu are noima ideea de istoricuri separate sau mai multe heads (gen production1,production2,etc). Branches sunt foarte ok pt. teste care merg in paralel cu trunk, cu amendamentul sa se faca mereu merge in trunk inainte sa se mute tagul de release.
Pe de alta parte colegul meu e posibil sa aibe dreptate si sa vrem un trunk diferit spatial (nu doar temporal) de production. Evident ca toate howto-urile pe care le gasesc pe net sunt orientate spre software development, nu spre config management, asa ca nu prea gasesc use case similar cu al nostru.
Daca vreun sysadmin citeste chestia asta, e rugat sa-mi descrie cum au ei structurat repository-ul, sa pot lua exemplu. Mersi.
PS: scuze pt. terminologia handicapata, daca nu se intelege ce spun, corectati-ma 
2 Responses to “repository design – branch vs tag”
September 4th, 2009 at 9:41 am
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.
September 4th, 2009 at 11:06 am
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