Subversion howto

A HupWiki-ből...

(Változatok közti eltérés)
(Nevergone (vita) 16755 szerkesztésének visszaállítása.)
(Kiprób)
54. sor: 54. sor:
  $ cd /path/to/projectdir;
  $ cd /path/to/projectdir;
-
  $ svn import . file:///devdirs/svnlayout/trunk --message 'Mar kesz fajlok beimportalasa';
+
  $ svn import . file:///devdirs/svnrepos/MyProject2/trunk --message 'Mar kesz fajlok beimportalasa';
Visszamegyük a projects könyvtárba majd az svn checkout paranccsal letöltjük a projectek adatbázisát, hogy utána megkezdhessük velük a munkát.
Visszamegyük a projects könyvtárba majd az svn checkout paranccsal letöltjük a projectek adatbázisát, hogy utána megkezdhessük velük a munkát.

A lap 2007. augusztus 15., 20:34-kori változata

Tartalomjegyzék

Bevezetés

Ennek a howtonak a célja, hogy egy egyszerű példa segítségével bemutassa, hogy hogyan készíthetünk magunkanak Subversion verziókezelő rendszert UNIX like rendszeren, valamint arról, hogy meglévő projectjeinket hogyan helyezhetjük a felügyelete alá. A hogyan csak felületes, ezért a részletekért olvasd el az SVN-bookot

A példa

A példa szerint két projectet szeretnénk létrehozni: MyProject1 és MyProject2. A MyProject1 egy éppen most induló project lesz, amihez még nem tartozik egyetlen sor forráskód vagy egyéb fájl sem. A MyProject2 egy már létező projectnek fog készülni. Az eddig elkészült kódok eddig nem voltak verziókezelő rendszer által támogatva, ezt most szeretnénk beálltani.

Telepítés

A Subversion telepítéséhez érdemes az adott rendszer csomagkezelőjét használni telepítéshez, mivel az SVN megtalálható a legtöbb disztribúcióban. Aki mégis az eredeti forrást szeretné felhasználi, az letöltheti azt a Subversion honlapjáról
Debian alapú rendszerre az apt-get install subversion paranccsal telepíthetjük.

A struktúrák kialakítása

Mivel szeretjük, ha a dolgaink egy helyen vannak, ezért az SVN repositorykat és minden hozzájuk tartozó file-t egy helyre fogjuk tenni. Tegyük fel, hogy ennek egy külön partíciót tartunk fennt, amit a /devdirs könyvtárba csatoltunk fel. Lépjünk be a mappába a cd /devdirs; paranccsal. Készítsünk egy svnlayout nevű mappát, ebben létrehozzuk az SVN repositoryk sablon szerkezetét, ami az alap esetben ajánlott trunk, branches és egy tags mappából áll. A trunk mappa tartalmazza majd a fejlesztői ágat. A branches a dokumentumok, programok egyes ágainak van fenntartva, így pl. a verziókat is itt tárolhatjuk egymástól elkülönítve. A tags mappában egy-egy pillanatképe szokás tárolni, így ha van egy jól működő változatod egy programról amit később módosítani szeretnél, előtte készíthetsz róla egy taget, mintegy extra backupként

$ mkdir svnlayout;
$ mkdir svnlayout/{trunk,branches,tags};

Ezzel létrehoztuk azt a könyvtárszerkezetet, amit minden projectnél használni fogunk.
Ezen kívül még könyvtárra lesz szükségünk, egyik ahol az SVN adatbázisok leszenk tárolva ez lesz az svnrepos könyvtár valamint egy, ahol a projectjeink lesznek, itt fog zajlani a tényleges munkavégzés. A könyvtár neve projects lesz.

$ mkdir {svnrepos,projects};
/devdirs
|--svnlayout
|  |--branches
|  |--tags
|  |--trunk
|--svnrepos
|--projects

Ettől a szerkezttől természetesen el lehet térni, az SVN-ben erre vonatkozóan semilyen megkötés nincs.

Tárolók létrehozása

Eljött az idő, hogy elkészítsük projectjeink tárolóját. Ehhez először létrehozzuk a projectek könyvtárát az svnrepos könyvtárban majd az svnadmin paranccsal létrehozzuk magát a tárolót, ahol az adott projecthez tartozó összes információ tárolva lesz. Egyúttal hozzuk létre a projects könyvtárba is a megfelelő könyvtárakat.

$ mkdir {svnrepos,projects}/{MyProject1,MyProject2};
$ svnadmin create --fs-type fsfs svnrepos/MyProject1;
$ svnadmin create --fs-type fsfs svnrepos/MyProject2;

Az fs típusa Berkeley DB (bdb) vagy FSFS lehet, ez az opció elhagyható. Röviden annyit róluk, hogy a bdb régebbi ezért lassabb, több helyet foglal a háttértárolón, stb. Az FSFS régebbi verzióval állítólag voltak problémák, de ugye miért is használnánk régebbit? A Subversion 1.4-es verziójától az FSFS-t részesítik előnyben.
Hozzuk létre az svn sablon szerkezetét úgy, hogy az előzőleg az svnlayout könyvtárban elkészített szerkezetet beimportáljuk a frissen megcsinált repoba:

$ cd svnlayout
$ svn import . file:///devdirs/svnrepos/MyProject1 --message 'Struktura letrehozasa';
$ svn import . file:///devdirs/svnrepos/MyProject2 --message 'Struktura letrehozasa';

Tárolók feltöltése és használatba vétele

Mivel a MyProject2 egy létező projectünk, ezért a trunk könyvtárába beimportáljuk a már létező fájlokat.

$ cd /path/to/projectdir;
$ svn import . file:///devdirs/svnrepos/MyProject2/trunk --message 'Mar kesz fajlok beimportalasa';

Visszamegyük a projects könyvtárba majd az svn checkout paranccsal letöltjük a projectek adatbázisát, hogy utána megkezdhessük velük a munkát.

$ cd /devdirs/projects/MyProject1;
$ svn checkout file:///devdirs/svnrepos/MyProject1 .;
$ cd /devdirs/projects/MyProject2;
$ svn checkout file:///devdirs/svnrepos/MyProject2 .;

Ezután a projectek trunk könyvtárában elkezdhetjük a munkát.

Munka közben

Most, hogy készen vagyunk a repositorykkal, elkezdünk velük dolgozni. Továbbiakban csak a MyProject1-en végzünk műveleteket, ugyanis az ezzel kapcsolatos dolgok használhatóak már a MyProject2-nél is. Minden további műveletet a /devdirs/projects/MyProject1 könyvtárban végzünk.
Esetenként a parancsok kimenetét is feltüntetem a howtoan.

File hozzáadása

Mivel a projectünk egyenlőre egyetlen fájlt sem tartalmaz, tulajdonképpen haszontalan. Készítsük hát el a hozzá tartozó első fájlunkat, aminek adjuk a first.file nevet. touch first.file;. Az svn status paranccsal lekérdezhetjük a változásokat. Most a következő kimenetet fogjuk kapni:

$ svn status
?      first.file

Láthatjuk, hogy a first.file előtt egy kérdőjel szerepel. Ez azt jelenti, hogy a fájl még nem áll verziókezelés alatt. Ezért az svn add paranccsal adjuk is hozzá a repositoryhoz.

$ svn add first.file;
A         svn-howto.wiki

Ekkor a fájl még csak az svn helyi adatbázisához lesz hozzáadva, ahhoz, hogy ez a repositoryban és így a munkatársaknál is megjelenjen, commitolnunk kell.

$ svn commit -m 'first.file file hozzaadsa';
Transmitting file data .
Committed revision 2.

A -m a --message rövidítése
A kimenetken látható Committed revision 2. sor jelzi, hogy az utolsó commit hanyadik változtatás repositoryban.

File törlése

Előfordulhat, hogy munka közben egy file feleslegessé válik ezért töröljük azt. A törlés demonstrálására hozzunk létre egy ideiglenes fájlt, adjuk hozzá a repositoryhoz, commitoljuk majd töröljük azt az svn delete paranccsal:

$ touch second.file;
$ svn add second.file
A         second.file
 
$ svn commit -m 'second.file hozzaadasa';
Adding         trunk/second.file
Transmitting file data ..
Committed revision 3.
 
$ svn del second.file
D         second.file
 
svn ci -m 'second.file torlese';
Deleting       trunk/second.file
Committed revision 4.

Commitoláskor a file törlődik a merevlemezről is viszont hála annak, hogy korábban commitoltuk az svn-ből bármikor visszaállíthatjuk azt, ha mégis szükségünk lenne rá. Ezt majd az svn merge paranccsal tehetjük meg - részletesen később.

Helyi változtatások visszavonása

Tegyük fel, hogy változtatásokat végeztünk a repositoryban, azonban commitolás előtt meggondoljuk magunkat. Példának vegyük a fájl törlést.
Commit előtt mindig érdemes és ajánlott megtekinteni, hogy mely fájlokat változtattuk meg:

$ svn st
M      first.file
D      second.file

Az svn status parancs hatására láthatjuk, hogy a first.file nevű file tartalma módosult valamint a second.file nevű fájlt törlésre jelöltük ki. Ekkor azonban eszünkbe jut, hogy szükségünk lehet még a second.file-ra, ezért szeretnénk visszavonni a rá vonatkozó törlést. Ezt az svn revert paranccsal tehetjük meg.

$ svn revert tmp.file
Reverted 'second.file'
$ svn st
M      first.file

A törlést visszavontuk és ha most commitolunk, akkor csak a first.file módosításai fognak felkerülni a repositoryba.

Serveren lévő változások letöltése

Mivel az SVN repositoryt nem egyedül használjuk, hanem a fájlokat mások is szerkesztik, ezért gyakran megesik, hogy munkatársaink is változtatásokat commitolnak. Ebből adódóan a helyi fájlok régebbiek, mint a serveren lévők. Ahhoz, hogy a local gépen és a serveren lévő verziók megegyezzenek, le kell töltenünk a változásokat az svn update paranccsal:

$ svn update
U    first.file
Updated to revision 8.

Ahhoz, hogy elkerüljük a konfliktusokat (azok az esetek, amikor a serveren lévő verzió újabb, mint a helyi, viszont a helyi fájlunkon is módosítottunk már, tehát nem összeegyeztethető különbségek is lehetnek), a lehető leggyakrabban töltsük le a változásokat és módosításokat követően (miután meggyőződtünk, hogy az elvégzett változtatások nem okoznak gondot a programokban) azonnal commitoljunk.

Branch létrehozása

Branchet akkor hozunk létre, ha valami olyasmivel szeretnénk kísérletezni, ami nem feltétlenül illik bele az aktuális fejlesztő ágba (trunk). Ilyen lehet például ha mondjuk valamelyik programkönyvtárat le akarjuk cserélni egy másikra. SVN-ben ilyenkor csupán annyit teszünk, hogy a trunkot átmásoljuk a branches könyvtárba.

$ svn cp file:///devdirs/svnrepos/MyProject1/trunk file:///devdirs/svnrepos/MyProject1/branches/branch1 -m 'branch1 letrehozasa'

Committed revision 13.

Ezzel még csak a repositoriban van létrehozva a branch, ahhoz, hogy ez helyben is meglátszódjon, csináljunk egy svn update-et a projectünk gyökérkönyvtárában!

$ cd ..
$ svn up
A    branches/branch1
A    branches/branch1/first.file
A    branches/branch1/second.file
Updated to revision 13.

Összeolvasztás (merging)

Miután a branchben elvégeztük a szükséges módosításokat és úgy gondoljuk, hogy alkalmas arra, hogy a módosítások bekerüljenek a fejlesztői ágba, olvaszuk be azokat, majd commitoljunk is egyet. A parancsokat a project trunk mappájában adjuk ki!

$ svn merge -r 13:HEAD file:///devdirs/svnrepos/MyProject1/branches/branch1
U    svn-howto.wiki
 
$ svn ci -m 'branch1 beolvasztasa a fejlesztoi agba'
Sending        trunk/svn-howto.wiki
Transmitting file data .
Committed revision 15.

A HEAD a branch legutolsó változatát jelöli. Beolvasztás történhet fordítva is, tehát a trunkban történt változásokat beírhatjuk a branchbe. A parancsokat a branch mappájában adjuk ki

$ svn merge -r 13:14 file:///devdirs/svnrepos/MyProject1/trunk

Összeolvasztáskor a branchre vonatkozó referencia pontként annak létrehozásánák revíziós számát használjuk, itt 13!

FIXME

Tag létrehozása

A tag létrehozásának módja megegyezik a branch létrehozásával. Ez esetben nem a branches mappába másolunk, hanem a tags mappába.

$ svn cp file:///devdirs/svnrepos/MyProject1/trunk file:///devdirs/svnrepos/MyProject1/tags/tag1 -m 'tag1 letrehozasa'

Visszatérés korábbi verzióhoz

Gyakran megeshet, hogy csak commit után jövünk rá arra, hogy nem jó a változtatás, amit végeztünk. Ekkor ugye szeretnénk visszavonni a commitot, amit svn-ben az svn merge paranccsal tehetünk meg. a példában a trunk mappában történt 17. commitot vonjuk vissza. Az svn merge után egy svn commitra is szükség van, hogy érvényesítsük a változtatásokat

$ svn merge -c -17 file:///devdirs/svnrepos/MyProject1/trunk
U    svn-howto.wiki

A -c kapcsoló a --change rövidítése.

$ svn st
M      first.file
 
$ svn ci -m 'undoing change committed 17'
Sending        trunk/first.file
Transmitting file data .
Committed revision 18.

Másik módszer, ha a --change helyett a revíziós számokat adjuk meg:

$ svn merge -r 19:16 file:///devdirs/svnrepos/MyProject1/trunk
U    first.file

A példában a 19-es revisionről a 16-osra tértünk vissza.

Konfliktusok kezelése

Vegyünk egy példát arra, hogy hogyan jöhet létre konfliktus: Van két felhasználó, Joe és John. Joe commitolt utoljára (revision 21), amit John szépen le is tölt az svn up paranccsal. Ekkor Joe szerkeszt valamit a fájlon, amit szépen fel is commitol (revision 22), azonban eközben John is szerkeszette a sajátját. Commit előtt természetesen leellenőrzi, hogy a repositoryban lévő verzió megegyezik-e a sajátjával:

$svn up
C    first.file
Updated to revision 22.

Itt láthatjuk, hogy a first.file előtt egy C karakter szerepel, ami egyenlő azzal, hogy az svn confliktust érzékelt. Ebben az esetben minden konfliktusban érintett fájl mellé létrehoz az svn létrehoz további 3 fájlt:

  • filename.mine: ez a fájl az aktuálisan szerkesztett fájloddal egyenlő. Nem tartalmaz konfliktus jelölőket.
  • filename.rOLDREV: Ebben a fájlban az utolsó checkoutod szerinti állapot van, mielőtt bármiféle változtatást végeztél volna rajta.
  • filename.rNEWREV: Ez az a fájl, amit a Subversion kliens a szerverről letöltött, amikor az svn up parancsot futtattad. Ez a fájl megegyzik a repository HEAD revízójával.

Az OLDREV a .svn könyvtár, a NEWREV pedig a repoistory HEAD revíziós számát jelenti.

 $ ls -1
 first.file
 first.file.mine
 first.file.r21
 first.file.r22

Ha most megpróbálunk commitolni, a Subversion nem fogja engedni:

$ svn ci -m 'try to commit'
svn: Commit failed (details follow):
svn: Aborting commit: '/devdirs/svnrepos/MyProject1/trunk/first.file' remains in conflict

Konfliktus esetén három dolgot tehetünk:

  • Kézzel összeolvasztod a konfliktusban érintett fájlokat
  • Az egyik ideiglenes fájllal felülírod a munkafájlod
  • Futtatod az svn revert <filename> parancsot, amivel az összes változtatásod visszavonod

Ha egy konfliktust megoldottál, ezt tudatnod kell a Subversionnel is, amire az svn resolved parancsot használhatod. Ez törli az ideiglenes fájlokat valamint az svn nem fogja konfliktusban lévőként érzékelni a fájlokat.

$ svn resolved first.file
Resolved conflicted state of 'first.file'

Kézi összeolvasztás

Kézi összeolvasztást akkor szoktuk használni, amikor mindkét verzió tartalmaz olyan módosításokat, amikre szükség van. Konfliktus esetén az svn konfliktus jelölőket a munkafájlunban, melyek arra valók, hogy könnyen azonosítani tudjuk a különbségeket:

$ cat first.file
1. sor
2. sor
3. sor
4. sor
<<<<<<< .mine
John 5. sor
John 6. sor
John 7. sor
=======
Joe 5. sor
Joe 6. sor
Joe 7. sor
>>>>>>> .r25

Látható, hogy a kérdéses rész két szakaszra van osztva: az egyik a saját módosításainkat tartalmazza, a másik a HEAD-ben lévőket. Ha szeretnénk a saját és a HEAD változtatásait is megtartani, egyszerűen töröljük ki a jelölőket, futtassuk le az svn resolved parancsot, majd commitoljunk.

$ cat first.file
1. sor
2. sor
3. sor
4. sor
John 5. sor
John 6. sor
John 7. sor
Joe 5. sor
Joe 6. sor
Joe 7. sor

$ svn resolved first.file
Resolved conflicted state of 'first.file'

$ svn ci -m 'A sajat (John) modositasaink beolvasztasa Joe sorai ele'
Sending        first.file
Transmitting file data .
Committed revision 26.

Saját verziónk kikényszerítése

Ha úgy ítélük meg, hogy a saját verziónk való inkább a repositoryba, akkor csupán elég felülírni a munkafájlt a módosításainkat tartalmazó ideiglenes fájllal:

$ svn up
C    first.file
Updated to revision 30.

$ ls first.file*
first.file first.file.mine first.file.r29 first.file.r30

$ cp first.file.r30 first.file

$ svn resolved first.file
Resolved conflicted state of 'first.file'

$ ls first.*
first.file

Commit és már kész is.

Szerveren lévő verzió elfogadása

Ha úgy gondoljuk, hogy a szerveren lévő verziónak van nagyobb létjogosultsága, akkor csupán futtassuk le az svn revert <filename> parancsot, ezzel visszavonva saját módosításainkat.

Parancsokról röviden

A helyi és a repositoryban lévő változatok közötti különbségeket az svn status paranccsal kérdezheted le. Ha a serveren lévő verzió újabb, mint a nálad lévő, az svn update paranccsal letöltheted azt. Az általad elvégzett módosításokat az svn commit töltheted fel a szerverre. Commitkor erősen ajánlott a message mező kitöltése, ezzel jelezheted magadnak és a projecten dolgozó munkatársaidnak, hogy milyen változtatásokat eszközöltél.

svn commit --message 'code tisztitas'

Új fájlokat az svn add paranccsal adhatsz a projecthez, fájlokat törölni az svn delete, régebbi verziót visszaállítani az svn revert paranccsal lehet. További gyakran használt parancsok: svn diff, svn update, svn help, stb. Az svn parancsok egy részét rövidítheted:

  • svn commit = svn ci
  • svn checkout = svn co
  • svn status = svn st
  • svn update = svn up
  • svn diff = svn di
  • svn delete = svn del vagy svn rm
  • svn move = svn mv
  • svn copy = svn cp
  • svn list = svn ls
  • svn switch = svn sw
  • stb.

Az SVN-bookot legalább egyszer mindenképpen olvasd el, hogy megértsd az itt felsorolt megoldásokat és parancsokat, megismerd az SVN a működését, filozófiáját és a benne rejlő lehetőségeket. Ez a rövid dokumentáció csak arra szolgál, hogy gyorsan létre tudj hozni egy működő svn repository-t, ezért nem helyettesíti a kézikönyv egyik szakaszát sem.

Forrás

A leírás alapjául az ajnasz.hu oldalon megjelent cikk szolgált. Ez annak egy lényegesen kibővített változata.

Személyes eszközök