© 2006 IND Group Subversion „védd meg a forráskódot önmagadtól” „ha nincs a repository-ban, akkor nem is létezik” Státusz: Kidolgozás alatt Verzió: 0.2.

Az előadások a következő témára: "© 2006 IND Group Subversion „védd meg a forráskódot önmagadtól” „ha nincs a repository-ban, akkor nem is létezik” Státusz: Kidolgozás alatt Verzió: 0.2."— Előadás másolata:

1 © 2006 IND Group Subversion „védd meg a forráskódot önmagadtól” „ha nincs a repository-ban, akkor nem is létezik” Státusz: Kidolgozás alatt Verzió: 0.2 Módosítva: 2007-02-12 Készítette: Lipták Gábor, Kolotenkó Sándor Bizalmasság: Nyilvánosan használható

2 2 SVN vs. CSV SVN célja kimondottan a CSV leváltása volt Könyvtár verziózás (mozgatás és átnevezés) Atomi műveletek Bináris diff fájlok közlekednek, így gyorsabb Fájl és könyvtár metaadatok tárolása Kevesebb hálózati forgalom Egy állapot egy revízió számmal azonosítható

3 3 Forráskód kezelés A forráskód változásait nyomon követő és ellenőrző rendszer „version control”, vagy „revision control” Primitív változat a mentés készítése, mely nem elégséges!

4 4 Miért használd? Fájl verzió menedzsment Release verzió menedzsent Változások mentése, nem az egész új fájllé Változtatások története Központi forráskód tárolás Csapatmunka támogatása Korábbi változások visszakeresése, és visszagörgetése Több fejlesztési szál támogatása Változások átvezetése egyik szálról a másikra Fejlesztő szabadsága, és gépfüggetlensége Mentési stratégia

5 5 Miért használd? Verziók élnek a repositoryban  Visszaállhatsz korábbi verzióra  Összehasonlíthatsz verziókat Konkurrencia támogatása. Nincs ilyen gond:

6 6 Verziókezelési koncepciók Repository  Központi adatbázis minden fájl minden verziójáról  Ritkán van szükség több repository-ra egy termékhez  Változásokat tárol, így kicsi a mérete viszonylag  Nem olvasható az ember számára  Lehet lokális és távoli Working copy  Ez az ami kijön a repository-ból  Egyszerű könyvtár, pl. Eclipse projekt  Átírhatsz amit akarsz, mások nem látják egyből .svn könyvtár minden könyvtárban. Ne töröljük soha Információk a repository helyéről, elérési adatok Utolsó módosítatlan verzió a fájlokból Minden fájl és könyvtár revízió száma

7 7 Verziókezelési koncepciók Revision number  Egy bizonyos állapot egy bizonyos időpont által azonosítva  Gyakorlatban a „revision number” azonosítja, mely az SVN-ben egy számláló  Bármely módosítás lépteti Új, módosított, vagy törölt fájl Új, módosított vagy törölt könyvtár „Ignore list” is ide tartozik Head revision  Egy adott fájl, vagy könyvtár legújabb verziója Working base  A working copy egy fájljának módosítatlan változatát jellemző revision number

8 8 Verziókezelési műveletek Importálás  Már meglévő, de verziókezelés alatt nem álló fájlok elhelyezése a repositoryban.  Repository változik Checkout  A repositoryból egy könyvtár kivétele a helyi gépre. Working copy létrehozása.  A repository változatlan marad Update  Változások rávezetése a working copy-ra.  Csak a változások közlekednek, tehát gyors.  A repository változatlan marad

9 9 Verziókezelési műveletek Commit  Változások megerősítése, és beküldése a repository-ba.  Csak a változások közlekednek, tehát gyors.  A repository változik, a working copy-ban a revíziós számok változnak Revert  A working copy változásainak visszagörgetése.  Nem kell kapcsolat a repositoryval, mivel az eredeti fájlok a.svn könyvtárakban vannak  Repository változatlan marad Merge  Ütközések esetén update művelethez kapcsolódik  Egyik szál változásainak átvezetése a másikra  Repository változatlan marad

10 10 Tipikus munkafolyamat 1.Repository létrehozása 2.Importálás 3.Working copy checkout 4.Fájlok szerkeztése 5.Update 6.Szükség esetén mergelés és konfliktusok feloldása 7.Commit 8.Ugrás a 3-as lépésre

11 11 Konkurrencia kezelése - Lock Bináris fájlok esetén szükséges feltétlenül

12 12 Konkurrencia kezelése - Merge

13 13 Konkurrencia kezelése - Merge

14 Branch kezelés Mit jelent a „branch”? Közös forráskódon alapuló, párhuzamos, független verzió fejlesztése. Az 1-es Branch-et a T1 időpontban hoztuk létre Branch-ek létrehozása után fejlesztések egymástól függetlenül és párhuzamosan folytatódhatnak. 14 Eredeti verzió Branch 1 Branch 2 Idő T1 T2

15 15 Közös forráskódon alapuló, párhuzamos, független fejlesztésre Fejlesztési szál elválasztása fix-pack létrehozás miatt: Termék verzió 1 Fix Pack – Termék verzió 1 Idő Termék Verzió 2 V1 elszállított Branch kezelés - Példa

16 16 Miért érdemes használni Branch-et? Sokkal biztonságosabb mód forráskód változások kezelésére és átvezetésére, nem zavar más fejleszőket munkájukban Izolált fejlesztés forráskód ellenőrzéssel

17 17 A Branch tulajdonságai Subversion-ban „Cheap copy” (kevés erőforrást igénylő másolat) – létező ágra mutató directory bejegyzés  Ugyanaz mint alias  Időt és helyet spórol  Fizikailag az új szál egy hivatkozás egy könyvtár egy bizonyos verziójára A rendszer a többi repository fájltól függetlenül kezel branch fájlokat.  Egy branch-en belüli fájl módosításai nem tükröződnek az eredeti fájl történetében

18 18 Mi a Tag? Egy “fénykép” egy bizonyos projekt állapotáról Egy kicsit több mint revision  Szöveges, jobban leíró név lehet Példa: kolbasz_release_1_5 vs. Rev 256 Branch-hez nagyon közeli fogalom  Egyetlen kivétel az, hogy nem módosulnak a fájlok

19 19 Mire jó a Tag? Revisiok azonosítására  Példák: Verzió 1.0 First revision to have a certain feature included Revision for upgrading to Java 1.5 Kolbász revizió 1.2 Stb.

20 20 Branching problémák Előfordulhat, hogy merge-lni kell branch-et az eredeti repository-val. Párhuzamos fejlesztés során alakulhatnak egyforma módosítások  Példa: konstans érték módosítás forráskódban Létezik megoldás ezekre a problémákra: merging (merge-lés)

21 21 Mire jó a Mergelés (Merging)? Egy fájl revizió más revizióba való illesztésre  Néha alkalmazható könyvtárok (folder) esetén is. X Y XX’ Y’ X’’ Y’’ X’’’

22 22 Repository elrendezés Branch-elés és merge-lés egyszerűsítésre a következő könyvtár felépítése alkalmazandó: branches/ tags/ trunk/

23 23 Egy jó fejlesztő… Azért használ branch-elést és tag-eket mert azok kevés erőforrást igényelnek!  Rendkívül hasznos, ha gyorsan növekszik a repository mérete  Mindig létrehoz egy branch/tag-et release után. Ezzel elősegíti a javításokat release módosítás nélkül. Betartja a megnevezési szabályokat Nem check-out-olja a root repository-t  Túl sok időt és helyet igényel, ha magas a branch- ek/tagek száma

24 24 Gyakorlati tanácsok Sose töröljünk a working copy-ban könyvtárat  Töröljük a repository-ban, majd update Valamit törlünk a repository-ban, ne ijedjünk meg. Nem tűnt el nyom nélkül.svn könyvtárakat ne bántsuk Néha kell a cleanup