Versioonihaldus

Versioonihaldus on tarkvara, dokumentide ja muu failidena säilitatava info muudatuste haldamine. Kõige lihtsamal tasemel versioonihaldust saab teostada käsitsi, tehes failidest aeg-ajalt varukoopiaid, kuid veakindlam moodus on kasutada spetsiaalset versioonihaldustarkvara. Viimased on eriti levinud tarkvaraarenduses, kus paljud programmeerijad töötavad korraga samade failidega.

Iga versioonihaldustarkvara keskseks komponendiks on repositoorium ehk hoidla – see on andmebaas, kus säilitatakse hallatava projekti kõiki redaktsioone. Vastavalt hoidla asukohale jagatakse versioonihaldustarkvarad tsentraliseerituteks ja hajutatuteks.

Tsentraliseeritud arhitektuuriga süsteemides asub hoidla keskses serveris. Töö tegemiseks tehakse repositooriumist kõigepealt väljavõte, töödeldakse faile ning salvestatakse failide seis uue sissekandena. Vältimaks konflikte, kui mitu kasutajat muudavad ühte ja sama faili, kasutatakse kas failide lukustamist või versioonide mestimist:

Lukustamise puhul valib arendaja enne töö alustamist failid, mida ta muuta kavatseb, mispeale versioonihaldustarkvara ei luba teistel kasutajatel nendes failides muudatusi teha seni kuni lukustaja on töö lõpetanud.

Kuigi lukustamine pakub kaitset konfliktide vastu, on sel ka suur puudus: see pärsib teiste arendajate tööd, kes tahaksid samuti parajasti lukustatud failiga tööd teha. Eriti tõsised probleemid tekivad juhul kui mõni arendaja lukustab suurema hulga faile või kui fail lukustatakse pikemaks ajaperioodiks (näiteks unustab töötaja enne puhkusele sõitmist luku vabastada). Lisaks kaasneb lukustamisega oht sattuda "tupikusse" – olukorda, kus kasutaja Anu on lukustanud faili A kuid peab töö lõpetamiseks tegema veel muudatuse failis B, mille on aga lukustanud kasutaja Bert, kes omakorda vajab töö lõpetamiseks faili A. Kõik need kirjeldatud probleemid tulenevad suuresti sellest, et arendajatel on raske ette aimata, milliseid faile neil on tarvis probleemi lahendamiseks muuta – lukustades liiga palju, pärsivad nad teiste arendajate tööd, lukustades aga liiga vähe, võivad sattuda ootama teiste taha või hoopis tupikusse.

Kirjeldatud probleemide tõttu kasutab enamik tsentraliseeritud versioonihaldussüsteeme tänapäeval lukustamise asemel mestimist.

Selle mudeli puhul saab mitu kasutajat muuta samu faile ühel ajal. Arendaja, kes saab oma muudatustega esimesena valmis, saab teha sissekande repositooriumisse ilma igasuguste probleemideta. Järgmine arendaja peab seejärel uuendama oma töökataloogi repositooriumist uueks versiooniks ning ühendama ehk mestima oma muudatused eelmise kasutaja tehtutega. Enamasti teevad arendajad muudatusi faili erinevates osades, sel juhul saab versioonihaldustarkvara ise automaatselt mestida.

Mestimisel baseeruvate süsteemide teerajajaks oli Concurrent Versions System (CVS), millest sai levinuim versioonihaldus vaba tarkvara projektide seas, kus lukustamise kasutamine oli eriti problemaatiline. Tänapäeval on levinumaks tsentraliseeritud süsteemiks CVS-i järeltulija Subversion.

Hajutatud arhitektuuri puhul on igal kasutajal kogu versioonide andmebaasist oma isiklik koopia. Töö tegemiseks kloonib iga kasutaja endale kogu repositooriumi, kuhu tehakse lokaalseid sissekandeid ja mida sünkroonitakse teiste kasutajate repositooriumitega. Tehtud muudatuste jagamiseks teiste kasutajatega lükatakse muudatused serverina käituvasse repositoorumi, kustkohast teised neid alla laadida saavad.

• Sõltumatus võrguühendusest – enamiku toimingute (commit, log, diff) jaoks pole võrguühendus tarvilik, sest neid tehakse kohalikus arvutis paiknevas repositooriumis. Tsentraliseeritud süsteemid seevastu vajavad pea iga käsu jaoks ühendust keskse serveriga.
• Kiirus – tulenevalt eelnevast on enamik toiminguid ka kiiremad.^[1]
• Privaatsus – kõik muudatused toimuvad kasutaja privaatses repositooriumis varjatuna teiste kasutajate eest seni kuni need otseselt avalikustatakse. Tsentraliseeritud süsteemides on aga iga versioonihaldusega tehtav toiming kohe kõigile kasutajatele nähtav.
• Turvalisus – ligipääsu pearepositooriumisse saab anda vaid valitud ringile usaldatud isikutele. Kõigil ülejäänutel jääb aga võimalus repositooriumi kloonida, sinna oma sissekandeid teha ja neid teistega jagada. Usaldusisikud saavad need muudatused oma isiklikku repositooriumi tõmmata, üle kontrollida ja alles seejärel pearepositooriumi suunata.
• Automaatsed varukoopiad – kui tsentraliseeritud süsteemi puhul tuleb kesksest repositooriumist pidevalt varukoopiaid teha, siis hajutatud süsteemi puhul pole selle järgi tarvidust, sest repositooriumi koopia on iga kasutaja arvutis.^[2]
• Võimalike protsesside paljusus – kasutades üht keskset repositooriumi kuhu kõikidel kasutajatel kirjutamisõigus on saab emuleerida tsentraliseeritud mudeli tarkvaraarendusprotsessi, kuid hajutatud arhitektuuri puhul on see vaid üks võimalikest protsessidest.^[3]

• Versiooninumbriteks kasutatakse hajutatud süsteemides enamasti räsikoode, mis pole nii lihtsalt meelde jäetavad kui tsentraliseeritud süsteemides kasutatavad lihtsad järjestikused numbrid 1, 2, 3, ....
• Esialgne kogu repositooriumi kloonimine on aeglasem kui kesksest repositooriumist üksnes viimase versiooni allalaadimine. See erinevus on rohkem teoreetiline, praktikas sõltub paljugi konkreetsest implementatsioonist.
• Hajutatud versioonihalduse kontseptsioonid on arendajatele raskemini mõistetavad, või vähemasti tuleb hajutatud süsteemi kasutajal tunda rohkem mõisteid kui tsentraliseeritud süsteemide puhul.

Hajutatud versioonihaldussüsteemid on leidnud kõige suuremat poolehoidu just vaba tarkvara arendajate seas. Paljud prominentsed avatud lähtekoodiga projektid on hüljanud tsentraliseeritud CVS-i ja Subversioni ning hakanud kasutama hajutatud süsteeme, millest populaarsemad on Git, Mercurial ja Bazaar.^[4]

Tsentraliseeritud süsteemid:

• CVS
• Subversion

Hajutatud süsteemid:

• Bazaar
• Darcs
• Git
• GNU arch
• Mercurial
• Monotone

Tsentraliseeritud süsteemid:

• Perforce
• Visual SourceSafe

Hajutatud süsteemid:

• BitKeeper
• ClearCase