Verziókezelés

Mi is az a verziókezelés?

Verziókezelés alatt több verzióval rendelkező adatok kezelését értjük. Célja az, hogy bármilyen módosítás visszakereshető, ellenőrizhető, visszaállítható legyen. Nyilván érzed, hogy az előző mondatban meghatározott követelmény korántsem egyszerű dolog, sok problémával és igénnyel kell ahhoz megküzdeni, hogy jó verziókezelő programokat állítsanak elő.
Bár a verziókezelő programok különféleképpen valósítják meg a verziókövetést, vannak bizonyos fogalmak, amikben megegyeznek.

1. Tároló, adatbázis (repository): a verziókezelés legfontosabb részeleme, ez tárolja az összes módosítást és a hozzájuk tartozó történetet. Ebből lehet lekérni egy állapotot (amelyet általában verziószámmal határozunk meg).
2. Munkamásolat (working copy): egy állapot (verzió) egy példánya (másolata), ezen tud dolgozni a fejlesztő.
3. Módosítás érvényesítése (commit): a változtatásokat úgynevezett commitok formájában érvényesíthetjük a tárolókon belül, melyek mintegy pillanatképként tartalmazzák azokat, illetve projektünk aktuális állapotát.Nagy általánosságban elmondható, hogy egy commit egyben verziómódosítás, így az verzió ugrást is jelent.
4. Módosítások lekérése (update): módosítások lekérése a tárolókból, azaz a munkamásolat frissítése a legfrisebb állapotra.
5. Fejlesztési történet (development history): commitok (és egyéb módosítások) összességére gondolj, az első (initial commit) committól kezdve az utolsóig (head commit).
6. Fejlesztési ág (branch): ha esetleg a tervezettől eltérő irányban is szeretnél továbbfejleszteni (kipróbálni valamit, vagy egy nagyobb módosítást indítani), akkor ún. elágazások segítségével az eredeti verziót érintetlenül hagyva tudsz kísérletezni, majd az elkészült módosításokat az éles kóddal összefésülni. A tag-től eltérően automatikusan felüliródik egy commit után, az új értéke pedig mindig az utolsó commit lesz, így a branch-ről elmondható, hogy követi a fejlesztés menetét.
7. Pillanatkép (tag): projekted fő vonalának, vagy bármely ágainak pillanatnyi állapotáról mentéseket, pillanatképeket, úgynevezett címkéket készíthetsz. A tagek maguktól nem módosulnak, ha egyszer beállítottad, akkor automatikusan nem változik, tehát nem követi a fejlesztés menetét. Gyakorlati haszna az, hogy a fejlesztés bizonyos pontját megjelölheted, felcímkézheted egy névvel, amelyre későbbiekben bármikor vissza tudsz állni, vagy legalábbis megtudod nézni az állapotát. Képzeld el azt a láma állapotot, mikor azt mondod, hogy: “Na, most lettem kész a legújabb módosításokkal, ezt most elmentem egy külön könyvtárba (F5 copy), és ha gáz van, akkor bármikor vissza tudom másolni az aktuális fejlesztésbe”. Nos, ennek vége a tagek használatával. A címkékhez létrehozáskor beszédes neveket szokás választani.
8. Összefésülés (merge): fejlesztési ágak egyesítése,melynek során a különféle ágak különféle verzióit tudod összefésülni, egyesíteni egyetlen verzióban
9. HEAD: a tárolóban lévő legutolsó commit szerinti változat
10. BASE: munkamásolatod alapjául szolgáló változat (azaz a legutolsó update commit változata)
11. PREV: a megelőző változat

Verziókezelők közötti eltérések

Bár sok apró dologban, megvalósításban különbözhetnek (más-más módon valósítanak meg feladatokat, komponenseket, eljárásokat), a legfontosabb megkülönböztetési szempont az a tároló központosított vagy elosztott volta.

Központosított rendszerek

A központosított rendszerek (pl. SVN, CVS),egy központi tárolóban valamilyen adatbázis segítségével (Svn esetében ez BerkeleyDB vagy FSFS) tárolják valamennyi kódunk történetét. A tároló bármilyen gépen lehet (távoli vagy helyi), elérése nagy általánosságban hálózat alapú.

A teljes kódállomány csak a tárolóban található meg (centralizált workflow), a fejlesztők innen kérik le (checkout) az aktuális állapotot, hogy munkamásolatot készítsenek.

Jellemző munkafolyamat a másolás – módosítás – összefésülés ciklus: elkészíted a munkamásolatodat, majd azon keresztül hajtod végre a módosításokat, amelyeket alkalmanként (egy nap többször is) érvényesítesz a tárolóban,majd amikor eljön az ideje, a változtatásokat összefésülöd a megfelelő ággal.

A verziókezelők ellenőrzik, hogy nem áll-e fent konfliktusveszély a módosított munkapéldány és a tárolóban található adatok között (azaz, az adott fájlt nem módosította-e valaki más, miután Te lekérted).

Elosztott rendszerek

Az elosztott szerkezet alapján minden fejlesztő (azaz munkamásolat) rendelkezik a tároló teljes másolatával

Ez a munkapéldánnyal azonos mappában helyezkedik el. Ez jelenti ezen rendszerek igazi erejét, ugyanis ez a módszer nagyban növeli a műveletek végrehajtásának sebességét (commit és update csak a helyi tárolóval kommunikál), és megszűnteti a központi meghibásodás veszélyét, mivel a központi tároló meghibásodás esetén bármely helyi munkapéldánnyal egyszerűen pótolható.

Jellemző munkafolyamat egyértelműen nem állítható fel, mivel az elosztottság sokféle munkafolyamat kialakítását teszi lehetővé. A központosított munkafolyamaton kívül felállíthatsz fejlesztői hierarchiákat is a csapaton belül. Ilyen az ún. integrációs menedzser munkafolyamat (workflow), ahol egyetlen fejlesztőnek (ő az integrációs menedzser) van csak joga a központi tárolóbaba commitolni. A többiek mind a saját különálló tárolójukba pusholnak, innen húzza át az integrációs menedzser a commitjaikat a központi tárolóba.