version control nu e backup
cu dedicatie speciala pentru colegul care a innebunit iremediabil repo-ul de svn
Toate cartile serioase de system administration (Limoncelli, Burgess, Frisch, Nemeth, etc) repeta la fiecare 10 pagini cat de important e sa-ti tii scripturile si configurile in version control, dar intra foarte putin sau de loc in detalii de folosire a acestuia, astfel incat am vazut o gramada de sysadmini foarte bine intentionati care folosesc svn-ul intr-un mod execrabil (si dupa aia cand dau de git se plang ca e complicat pentru ca nu face cum se asteptau), asa ca notez cateva chestii care sunt adesea neglijate:
- version control se foloseste ca sa stii ce, de ce, cand si de catre cine s-a schimbat. in concluzie, vrei sa tii in VCS tot istoricul unui fisier, nu doar "last known good version"
- softurile de version control fac eforturi deosebite sa tina minte toate schimbarile, asa ca daca pun un iso de 700M in repository si il sterg mai tarziu, ala ramane in repository (evident ca exista hackuri sa te poti razgandi, dar e dureros)
- oarecum in aceeasi ordine de idei, cand muti sau redenumesti un fisier, fa-o in asa fel incat sa-i pastrezi istoricul (consulta documentatia clientului de VCS folosit)
- pentru ca in istoricul unui fisier se pastreaza referinte la toate commiturile, iar fiecare commit are mesajul lui, incearca ca atunci cand faci commit sa incluzi o descriere pertinenta a ceea ce inseamna. Asta il va ajuta nemaipomenit de mult pe cel care va incerca peste 6 luni sa afle de ce s-au schimbat fisierele alea
- nu uita atunci cand faci un commit, ca impingi bitii undeva mai in sus (sau in jos, daca vizualizezi "botanic" arborii logici), expunand astfel schimbarile alea catre clienti care urmeaza sa le copieze si pe care e posibil sa nu-i controlezi. Asa ca in general te poti razgandi doar inainte de commit, nu dupa (ma rog, de cele mai multe ori se poate, dar e mai costisitor). Foloseste un branch de test sau ruleaza unit teste inainte de commit sau verifica diff-ul sa nu ai parole prin el, etc.
- daca faci un repository nou, gandeste-te putin ce software vrei sa folosesti si ce vrei sa pui in el. Tine cont ca unele vcs-uri cum e git lucreaza cu intreg tree-ul, altele ca subversion lucreaza cu subdirectoare, iar cvs sau rcs lucreaza cu fisiere (ma rog, la rcs nu se pune problema de repository, dar poate fi o solutie inca viabila pentru anumite probleme de change management)
- daca ai subtree-uri care n-au legatura unul cu altul (nu se muta fisiere de colo-colo, nu trebuie tinute in sync commiturile, ai eventual acl-uri diferite, etc) e o idee sa fragmentezi in mai multe repo-uri, o sa fie mai usor sa le faci backup, pruning, branching, etc.
- ca tot vorbesc de branchuri: chiar daca pare overkill ("vreau doar sa am evolutia liniara in timp a fisierelor astea"), e bine sa citesti despre branchuri si taguri, ca sa stii sa le folosesti atunci cand va aparea nevoia. Daca faci un svn repo nou, fa-l cu standard layout (cu trunk, tags si branches in varf) si foloseste trunk pentru inceput, diferentele sunt practic inobservabile.
- nu uita ca pana la urma conflictele se rezolva prin discutie intre cei doi commiteri, nu vrei ca vcs-ul sa ia decizii de capul lui atunci cand doi insi incearca sa modifice aceeasi chestie. Asta inseamna ca toti cei din echipa sa stie cum sa identifice un conflict si care e policy-ul agreat (daca ai un workflow bine gandit, situatia asta ar trebui sa apara suficient de rar incat sa trebuiasca sa cauti cum se face)
M-am luat cu vorba si n-am ajuns la ideea din titlul postului. Daca ai niste date care vrei sa fie _undeva_, tine-le pe un file server (nfs,smb,ftp,web,dav,whatever) si mentioneaza in documentatie sau scripturi unde sunt. Daca e posibil sa ai un URL standard pentru o astfel de resursa, cu atat mai bine. Version control e extrem de costisitor pentru ceva pentru care n-ai nevoie de istoric.
Si nu in ultimul rand, un repository trebuie sa aiba backup! La DVCS-uri se poate face cu un client care se sincronizeaza cu 'serverul' oficial, dar la svn sau cvs e nevoie de backup traditional (si atentie la mentinut consistenta, ca la bazele de date, altfel te trezesti cu tot soiul de lock-uri prin backups, ceea ce implica o gramada de batai de cap la restore).
Bafta! Daca mi-a scapat ceva, dati-mi de stire.