Jó dolog tisztában lenni a manapság használatos verziókövető rendszerekkel, ha már egyszer ClearCase admin az ember.

Fapados, védőkesztyű viselése kötelező, aláírom. Kicsit nyögvenyelős Windows-on, de a rendszer nagyon jó. Rendben, volna mit javítani rajta, de alapvetően el bírnám képzelni, ha holnap a cég áttérne Git-re.

A Bazaar oldalán részletesen ismertetik, miért jobb az ő szoftverük, mint az X, mint pl. a Git: BzrVsGit.

Ami stimmelt:

1: A Windows support tényleg hibádzik, a fejlesztők rendszerint Windows-t használnak, és rendszerint Windowsra is fejlesztenek.

2: Nagyon szofisztikáltan néz ki az a sok SHA-1 kód, de biztosan jobban nézne ki, ha lefordítanák valami relatív nyelvre is (amire szintén lehetne hivatkozni), pl. master.25 a master branch 25. változása. Nem hiszem el, hogy annyira bonyolult lenne implementálni.

3: Aszinkron update-ek. Nem olyan rossz ez a patch küldés… nagyon hasonlít arra, ahogy karban kéne tartanom a FreeBSD ports szoftveremet: email-ben elküldeni a változtatást uuencode-olva kicsit lehangoló így a 21. században.

4: Tárolási modell. Nincs minden adatra szüksége a fejlesztőknek. Csupán néhány branch az, amit tényleg használnak. Legyen meg a lehetőségük a branch-ek egyenkénti klónozására is.

5: Library megközelítés: ha már van library, akkor arra már könnyebb bárhol elfutó kódot írni, nem feltétlenül C-ben. Szerintem ez az egyik legalapvetőbb problémája a Git Windows-osításának.

Ami sántított:

1: A Workflow támogatás szép, de hát tessék a megfelelő eszközt használni a megfelelő problémára. Nem beszélve arról, hogy miközben olyan checkineket látok embereknél, hogy “kivettem ezt-és-ezt a testcase-t, mert nem fut le”, nem hinném, hogy a tesztek sikeres lefutása lehetne bármiféle alapja a checkin-nek. Ha azt írják, hogy a sikeres integráció alapja legyen, még jobban elhiszem, már ha volt Code Review, vagy bármilyen ilyesmi.

2: A könyvtárak maguk a branch-ek. És ez mint feature. Ekkora marhaságot is régen hallottam. Ha nem különíted el a könyvtárstruktúrát a branch struktúrától, akkor összemosódnak. Megértem, hogy mindkettőnek a legjobb megjelenítési formája egy bizonyos könyvtárstruktúra, de teljesen másra való mindkettő, és ezeket nem szabad összekeverni!

3: Inkonzisztenciák. A Push és Pull közötti probléma alapvetően értelmetlen, hiszen push-olni csak a tulajdonos fog, míg pull-olni minden mókus tud. Teljesen másra való a két parancs. Automatikus merge/commit: ez azért nem probléma, mert valójában nem kerül bele semmilyen repóba (a sajátodon kívül), és könnyen lehet törölni is. Ez inkább azt erősíti, hogy mindent commit-olj, nehogy elvesszen az adatod.

4: Ismert parancsok. Senkit sem érdekel, hogy a cvs-nek vagy svn-nek milyen parancsai vannak. Ha komolyan fejlesztesz, nem mondhatod, hogy nem használsz verziókövető rendszert, vagy csak olyat, amilyet szeretnél. Azt használod, ami van. Ha éppenséggel Git van, akkor azt tanulod meg. Ha ClearCase van, akkor azt. Ha perforce, ha BitKeeper, akkor sincs választási lehetőséged. Ha mégis választhatsz, és inkább központi rendszert használsz, ott az SVN. Onnan bármikor áttérhetsz Git-re.

5: Könnyebb adminisztráció. Visszatérő tévhit a branch-mint-könyvtár, hogy ott több jogosultságot lehet kiadni. A disztributált modellnél pont az a lényeg, hogy a jogosultságellenőrzést a bizalomhálózat biztosítja (az integrátor bízik a fejlesztőiben, vagy ha bennük nem is, a tesztelőkben). A szemétgyűjtést is nagyon ügyesen oldja meg a cron job. A mentéssel kapcsolatban is túlparáztatja az embereket a szerző. Ami commit-elve van, az bent van a mentésben, ami meg nem volt, az nincs bent. A Git repót össze lehet harácsolni a fejlesztőktől, ha a cégnek magának nem volt mentési stratégiája, de hidd el, van.

6: Integrációs eszközök. Ismerek ilyeneket, a legtöbb ilyen bizony hook script volt, és nem éppen együtt adták a szoftverhez. Láttam már olyat, hogy SVN commit-ot ellenőrzött, hogy szép-e a kód, vagy hogy a hibajegy még nyitva van-e. Meg olyat, hogy beszólt a JIRA-nak, hogy érkezett commit, a commit message-t elküldve a hibajegy megjegyzésének. Ezek (== egy ilyen rendszer integrációja a verziókövetőbe) nem akkora feladatok, hogy egy szoftverfejlesztő ne tudná összeütni egy délután alatt.

Amit azért tovább kéne gondolni:

Git-ben bár lehet csinálni könyvtár-szerű branch neveket, azonban azok egyáltalán nem fa struktúrába rendeződnek. Nem lenne hülyeség, ha egy branch-et a hierarchiában fölötte levő branch-ből lehetne készíteni. Tehát ha a /master branch-ben vagyok, és csinálunk egy stable branch-et, az logikusan /master/stable nevet kapna. Nem tenném azonban kötelezővé, inkább könyvtár-szerű címzést vezetnék be, pl. ../../releng/v3.2/RC1. Természetesen a jó példát a ClearCase-ből hoztam.

Nem fenékig tejföl a tárolási modell sem. Szerintem a repót és a munkakönyvtárat igenis külön kell választani (mint ahogy a ClearCase-ben is van, de most mondhattam volna svk-t is akár). Több szkenárióm is van:

• Csoport jogok. Egy cégnél inkább van olyan eset, hogy valakit helyettesíteni, pótolni kell, mert mondjuk beteg, tanfolyamon van, vagy elmegy a cégtől. Ilyenkor a jogosultságai nem épp elérhetőek. Nem baj, ha több munkamásolat lehet egy repóról (amit nem feltétlenül eresztenek be a közösbe) anélkül, hogy még egyszer lemásolnánk a repót (a probléma másik felét a távoli repó adná).
• Távoli repó, helyi munkakönyvtár. Egy közepes-nagy cégnél már valószínű, hogy központi filer-en vannak az anyagok (pl. OpenFiler), mindenki el tudja érni valahogy. A repó műveletek amúgy sem esznek túl sok hálózati forgalmat, a nyilvános branch-eket én így tárolnám.

Sőt, igazából a submodule támogatás helyett kéne a working copy-t felerősíteni. Azért nem kéne annyira bonyolultra, mint a ClearCase-t, de el bírnám viselni, ha egy View-szerű repót össze lehetne hozni. Meg lehetne mondani, hogy milyen könyvtárakba milyen repókból melyik branch-et gyűjtse le, és módosítás (commit -a) esetén milyen branch-et hozzon létre.

Azt is el tudnám képzelni, ahogy a távoli repókat szinkronizáljuk: mondjuk minden repó tudja a többi távoli repót, hol van, és hogy épp hol tartanak (verzió). Ha van egy A, egy B, meg egy C repónk, és mondjuk A tudja, hogy B hol tart C-ben, de A-nak vannak újabb patch-ei, akkor az A->B szinkron során elküldi azt is. Így biztosítja, hogy mindegyik repónál a legfrisebb adatok legyenek. Na, honnan nyúltam az ötletet?