Az SVN-ről ahogy időm engedi, több bejegyzést is szeretnék majd írni. Most írok egy bevezetőszerűséget arról, hogy mire jó, s megosztok pár trükköt is, amit az utóbbi években sikerült összeszednem vele kapcsolatosan.
Az SVN, hosszabb nevén Subversion egy verziókezelő rendszer. Olyan, mint a CVS. Aki még egyiket sem próbálta, annak mindenképpen érdemes az SVN-t választani, mivel történelmi okokból sokkal bugmentesebb.
A verziókezelő rendszerek lényegét valószínűleg sokféleképpen el lehet mesélni. A legegyszerűbb egy olyan háttértárként felfogni ezeket, mint egy átlag bármilyen FTP, amely emlékezik a rá másolt fájlok korábbi állapotára is. Egy SVN tárhelyet “repository”-nak, egy vagy több fájl rendszerbe tételét “commit”-nak, a rendszerben levő fájlok lekérését pedig “checkout”-nak hívjuk. Minden commit után a rendszer egy új számot rendel a fájlok aktuális állapotához (egy commit után simán nő egyet ez a szám), amit “revision”-nek nevezünk. A commitokhoz egy rövid szöveges leírást lehet és érdemes rendelni, így később megtalálhatóak az egyes változtatások (pl. “hozzáadtam az xyz-t”, “töröltem xzy-t mert elavult volt”, “elgépelés javítása”, stb.). Az egyes állapotokra ezután ezekkel a számokkal lehet hivatkozni: “a 1129-es revisionban”, “a 231-es commitod után bedöglött a rendszer”, “visszaáltam a 42-es revisionre”, stb. Azt a műveletet, amikor kikérjük a rendszerből az aktuális legfrissebb állapotot (miután mások változtattak valamit), egyszerűen “update”-nek hívjuk.
A verziókezelő rendszereket csoportmunkára találták ki, de sokmindenre használhatóak. Érdemes lehet akkor is használni, ha egyedül dolgozunk fájlokon, mivel backupolásra is jól használható. Ha például a Dokumentumok mappát minden nap végén commitoljuk, akkor az egyes szerződések korábbi állapotához is hozzá tudunk férni, illetve ha elveszik az egész mappa, és a verziókezelő rendszerünk egy másik gépen van, könnyedén visszaállíthatunk mindent.
A klasszikus verziókezelő alkalmazás mindazonáltal forráskódok tárolása. A fejlesztéshez sok kényelmi lehetőséget biztosít, kezdve azzal, hogy ha valaki ugyanazon fájl különböző soraihoz nyúl, akkor lehetőséget biztosít összefésülésre: “merge”. A commitok “atomiak”, azaz nem fordulhat elő olyan, hogy két vagy több fejlesztő egyszerre commitol valamit, és felülírják egymás változásait. Valaki előbb fog commitolni, és a rendszer jelzi, hogy nem volt friss a helyi változata a fájlnak, előbb egy update-et kell lefuttatni. Az update során ha a rendszer el tudja intézni, akkor összefésülésre kerülnek a fájlok, és nekünk csak annyi dolgunk lesz, hogy becommitoljuk azokat. Ha ugyanazokon a sorokon történt a változtatás, akkor az automatikus összefésülés nem fog sikerülni, de kapunk négy fájlt, egy olyat, amiben jelölve vannak a helyi és a másik commitoló(k) által végzett változtatások, továbbá megkapjuk a verziókezelő legfrissebb fájlát, azt a változatot amit legutoljára kiszedtünk a rendszerből és a mi fájlunk is megmarad. Ez egy nagyon kényelmes szolgáltatás.
A verziókezelőből sok információt ki lehet nyerni, amellett hogy az egyes régebbi változatokhoz is hozzáférünk, ha valamit nagyon elrontottunk, vagy csak meg akarunk nézni egy régebbi változatot. Például le tudjuk kérdezni, hogy egy adott fájlhoz ki nyúlt utoljára, vagy hogy mi az adott fájl története, “history”-ja. Az adott állapotok közötti változások lekérhetőek, akár az egész rendszert, akár egy adott fájlt illetően.
A modern verziókezelők egyik lehetősége, és emiatt például érdemes az SVN-t választani az átláthatósága miatt, a commitok előtt és után lefuttatható scriptek lehetősége. A Weblabor fejlesztése a kezdetekben úgy zajlott például, hogy commit után az SVN csinált egy update-et a webszerveren, odamásolva a legfrissebb változásokat (alapból volt ott egy checkout, amit csak frissítenie kellett). Ez megoldotta az FTP-s szívásokat, amikor felülírtuk egymás változásait. A jelenlegi rendszer ezen is túlmegy, van egy fejlesztői URL, ahol a friss fejlesztések megjelennek, tesztelhetőek, és egy “piros gomb”, amit megnyomva a legfrissebb változatra frissíteni lehet az éles rendszert is. Érdemes lehet egy undo gombot is bevezetni, amivel vissza lehet állni a korábbi verziók bármelyikére, de erre a Weblabor esetén nem volt szükségünk, nagy változtatásokat ritkán csináltunk. Ezt a folyamatot nevezem “automatikus deploy” folyamatnak. Elég jól bevált a dolog.
Egy másik “deploy” folyamatot raktunk össze az egyik korábbi munkahelyemen, ahol például az volt a különbség, hogy sokkal biztosabban kellett működnie a rendszernek, és több éles szerver is volt (terheléselosztás kapcsán). A lényeg itt annyi, hogy több szerveren kell lefuttatni az update parancsot az éles rendszer frissítésekor, és ezt érdemes lehet egy kis scripttel elvégeztetni. A script belép a különböző szerverekre, lefuttatja mindenhol az update-et, és dolga végeztével szól, hogy készen van. Ilyen környezetekre egyébként kiváló eszköz lehet a Capistrano, melyet a Ruby on Rails-hez terveztek, de általánosan is kényelmesen használható. Most tanulgatom saját weblapom kapcsán.
Még egy trükk amit az SVN segítségével meg lehet oldani – azt automatizált minőségbiztosítás. Ha a projekt során különböző követelmények vannak például a forrásfájl formázását illetően, akkor a commit folyamatba beiktathatunk egy scriptet, ami leellenőrzi, valóban dupla szóközt használtunk-e tabulálásra (esetleg kijavít minket), nincs-e az adott forrásban syntax error. Lehet olyan scriptet írni, ami (pl. C-s fejlesztés esetén) csinál egy builded, s ha hibát talál a build során, akkor megakadályozza a beküldést, vagy a frissen beküldött forráson lefuttat előre elkészített teszteket, és küld egy emailt a teszteredményekkel. Vagy egy kis script segítségével az is megakadályozható, hogy megjegyzés nélkül küldjünk be egy commitet. A Weblabornál egy olyan scriptet raktam össze, mely a változtatásokról küld egy emailt az összes szerkesztőnek – lehet látni, hogy ha valaki dolgozik valamin, illetve hogy pontosan miket csinál. Több szem többet lát alapon könnyű kiszúrni más változtatásaiban a kis hibákat, és akár korrigálni is azokat (van erre egy jobb megoldás felkiáltással).
Végül, de nem utolsó sorban, a hibajegykezeléssel is össze lehet drótozni egy verziókezelő rendszert. Az egyik projektemben ha “fixes #1234″ üzenettel küldünk be egy változtatást, akkor a rendszer lezárja az adott hibajegyet a beküldő nevében, majd küld egy értesítést a tesztelő csapatnak, hogy ki lehet próbálni a változtatást. Iszonyat kényelmes. 
Ha valaki használ SVN scriptelést, kiváncsi lennék rá, hogy mire lehetnek jók még a gyakorlatban ezek a kis scriptek.
Még, még, még!
A bevezetéshez én annyit hozzátennék, hogy ha valaki elkezd SVN-t használni, akkor utánna már nem érti, hogy hogyan tudott előtte nélküle dolgozni.
Na végre egy jó leírás, köszi. Persze ha időd engedi, jöhetnek a részletek… nálam is nemrég merült fel, hogy szükség lenne egy verziókövető rendszer bevezetésére, de nulla tapasztalatom van ezen a téren.
Csak annyival egészíteném ki, hogy igazán hatékonyan szöveges fájlokkal működik, hiszen azokat lehet a legegyszerűbben összehasonlítani és ebben az esetben nem őriz meg minden változatot teljes egészében, hanem csak a változásokat. Ennek köszönhető, hogy bármikor bármelyik revision-t ki tudod szedni. Ugyan vannak kísérletek különböző bináris formátumú adatok kezelésére, de általában ott az egész fájl mentésre kerül, ami esetenként rendesen zabálja a tárterületet (persze ha gyakran változik).
Egy egyszemélyes projektnél is nagyon hasznos tud lenni!
Vannak akik azt mondják, hogy csak bizonyos fejlesztői szám felett érdemes használni verziókezelőt. Ezt persze ne fogadjuk el
A commit utáni azonnali frissítést az éles rendszeren egy kicsit veszélyesnek tartom, de valószínűleg ez is környezetfüggő megoldás. Én csak olyan projektben használtam cvs/svn-t, ahol komoly fordítási/buildelési feladatok is voltak (java), nem is beszélve a telepítésről. Magába a verziókezelőbe nem építettünk semmiféle extra logikát, ne foglalkozzon ő szintaktikával meg ilyenekkel. Íratlan szabály, hogy mielőtt valaki beküldi a változtatásait, előtte frissítse a lokális verziót és végezze el az ellenőrzést, hogy minden rendben van-e. Ezek után mehet a commit. Természetesen ennek ellenére is beállhat némi inkonzisztencia, ilyenkor jön jól, ha be van állítva, hogy éjjel/hajnalban egy automatizmus leszedi a kódot, fordít, buildel és küldi a státuszjelentést a projektvezetőnek. Ezek után remekül lehet pellengérre állítani azokat az embereket, akik figyelmetlenül küldözgetik be a javításaikat
A hibakezeléssel való összedrótozásról nekem egyből a trac jutott eszembe, mert bár létezik jópár hasonló, nekem ez a favoritom. Ez az a rendszer, ahol egybegyúrták a projektkezelést a verziókezelővel, a hibakezelővel (ami messze nem csak hibakezelő) és egy wikivel és nem mellékesen remek webes felületet biztosít az svn repository-hoz
.
Nagyon barátságos, őszintén ajánlom mindenkinek!
Köszönöm a kiegészítést, ez a szöveges-bináris rész például valóban kimaradt. Az éles rendszer update-je commitkor valóban veszélyes, csak az adrenalint kedvelőknek ajánlott.
Persze meg lehet spékelni azzal, hogy helyben mindenki kipróbálja magának a kódot egy saját változaton, de idág bevallom nem jutottunk el a Weblabor esetében anno (most készülök egy saját Weblabort összerakni helyben). Mondjuk ilyenkor rendszerint átgondolja az ember, hogy pontosan mit is küld be, és nem vadon küldözget be mindent.
A Trac valóban jó dolog, én is csak ajánlani tudom. A telepítése sajnos nem egyszerű, bár lehet, hogy ez az évek során változott, egyszerűsödött, nem tudom.
Dokumentumok és egyéb nem forráskód jellegű felhasználásra nagyon kényelmes dolog a DAV. Egy apache+svn párossal a repository-t webDAV protokollal mountolni lehet hálózati driveként, ezen közvetlenül dolgozhatunk és minden mentés egy új verziót fog jelenteni az adott dokumentumról. Ehhez be kell kapcsolni a szerveren az Autoversioning kapcsolót (Autoversioning on a megfelelő location/virtualhost szekcióban). Így nem kell checkoutolni és commitolni sem. Persze így nem lesznek megjegyzések az egyes verziókhoz, plusz nem minden dav kliens támogatja a deltaV-t, így ezekben az esetekben nem csak a változás, hanem a teljes file kerül bele a repository-ba, de mint tudjuk, ingyen leves nem létezik
Hibajegykezelő integrációhoz az Eclipse Mylyn pluginjét tudom ajánlani (persze a Subversive pluginnel együtt). A Mylynnel Bugzillához vagy trachez (vagy mantishoz, jira-hoz) lehet kapcsolódni ezek xmlrpc felületén lekéri a hibajegyeket, ezeket lehet szerkeszteni, és fókuszba lehet hozni egy adott hibát: amikor elkezdesz dolgozni egy hiba javításán akkor az érintett fileokat mutatja csak a projectben, commitkor automatikusan kitölti a megjegyzés mezőt a hibajegy számával, linket rak a hibajegyre, és beleírja a jegy állapotát is, természetesen ez az automatikus kitöltés template-n keresztül történik, így teljesen testre szabható.
Sziasztok,
Mi a menete annak, ha egy svn repo-ba lévő oldalt át szeretnék másolni webroot-ba, hogy tesztelni tudjam? Gondolom hook-okal commit-ok után lenne a legkézenfekvőbb. De mivel sem a perl, sem a bash script-ek nem az erősségeim, ezért valami útmutatót szeretnék kérni.
Ez működne? (Nem linux előtt ülök, így hirtelen nem tudom kipróbálni):
#!/bin/bash
svn export –username testuser –password testpass http://svn.pelda.com /var/www/honlap
A válaszokat előre is köszönöm.