Lucrul cu Subversion (SVN)

De când am început sa lucrez in programare, eram curios sa aflu cum se lucrează cu adevărat in echipe. De multe ori am lucrat in "echipa", dar de obicei aveam partea mea total izolata de munca celorlalţi. Fiind singurul coder PHP la firmele unde lucrasem, nu am avut niciodată probleme sau conflicte la nivelul codului cu ceilalţi programatori.

Acest lucru s-a schimbat când luna trecuta am primit un proiect nou.. S-a format o echipa de 3 programatori, si urma sa scriem soluţia in Java.

Fiind un proiect mare (momentan suntem pe la 3k linii de cod / persoana) am avut nişte nelămuriri despre cum sa facem acest lucru împreună fiindcă lucram pe acelaşi clase.

Unde publicam ultima revizie? Ce facem daca sunt conflicte? etc.

Asa ca am decis sa încercam folosirea unui server SVN. (subversion.tigris.org)
Am instalat un client pentru NetBeans, extensia numita "Subversion", si am instalat pe un server apache: mod_dav si mod_svn.

Workflow cu SVN:
0. Se creaza un repository pe server.
1. Dimineata se face un "Update" la intregul proiect.
2. Dupa ce se termina o sesiune de programare, se face inca o data un "Update". Astfel coderul va avea ultima revizia de pe server. Clientul SVN va combina codul cu ceea ce are coderul pe calculatorul sau.
3. Se cere un "Commit" care va copia revizia curenta pe server si ii va adauga un "tag".

Explicatii:
Update: aceasta opţiune va descărca de pe server ultima revizie, si va marca in cod daca sunt conflicte. Daca nu sunt conflicte la nici un fişier, atunci va face un merge automat intre revizie si codul programatorului. Daca sunt conflicte, va face un merging dar va marca locurile unde sunt probleme, si le va pune in brackets-uri "mine" si "rev.xxx", urmând ca programatorul sa le rezolve manual.

Commit: Va face o noua revizie, si va copia ceea ce are programatorul modificat pe calculator + fişierele noi.

Observatii
Nişte observaţii care vin din greşelile pe care le-am făcut noi:

1. Inainte de COMMIT se va face un UPDATE obligatoriu. In caz contrar, revizia programatorului va fi copiata, si se vor pierde modificările de pe server care au intervenit de la ultimul sau "Update"

2. Commit/Update nu este tabu, si se foloseşte de cate ori este finisata o funcţie sau un feature.

3. Se testează programul înainte de commit măcar pentru greşeli sintactice/path-uri/fişiere care lipsesc etc. (sa nu fie revizia cu erori)

4. La fiecare Commit se poate ataşa un mic text care explica ce a fost schimbat/adaugat. Folosiţi-o, e f. util când sunt conflicte de rezolvat.

5. Se include la comit doar fişierele sursa si resursele. Fişiere de build, exe, configuraţii etc nu trebuie sa intre in versiuni fiindcă se vor schimba automat tot timpul. De exemplu in java la un proiect nou se importa doar directorul SRC si directorul de resurse, restul se exclude din SVN.

- un log svn -

Reviziile sunt numerotate. Daca sunt probleme sau conflicte ne rezolvabile, se poate lucra cu o revizie anterioara.

Sunt mai multe soluţii client pentru svn. E prefer sub windows TurtoiseSVN. Un client superb de bine realizat, care oferă mai multe funcţii utile pentru gestionarea subversiunilor decât componenta Subversion pentru NetBeans.