Subversion

• Vytvoření repozitáře
• Stažení projektu
• Vložení souborů do projektu
• Práce se soubory
• Slučování změn
• Konflikty
• Cestování časem
• Větve (branches) a tagy

Vytvoření repozitáře

První, co musíte udělat, pokud chcete používat SVN, je vytvořit repozitář a nahrát do něj váš adresář. Tím vytvoříte první verzi.

Architektura Subversion

Jako příklad projektu použiji zdrojové soubory k programu Známky a kredity (ver. 4.01) (je součástí zdrojových kódů). Po rozbalení zdrojových kódů uvidíte v adresáři 11subversion adresáře var/svn, Windows a znamky4.01.

Adresář var/svn budu používat pro uložení repozitářů. Normálně se v Linuxu používá adresář /var/svn/, ale repozitář můžete mít uložený kdekoliv. (Já třeba ukládám svoje repozitáře do adaresáře ~/.svnRepository.)

V adresáři znamky4.01 je uložený neverzovaný projekt (to se ale brzo změní). Adresář Windows představuje nějaký jiný počítač, kde budu pracovat s druhou kopijí projetku.

Krok číslo 1 je vytvoření repozitáře.

A to je celé. svnadmin je program, který se používá pro administraci repozitáře. Umí toho víc než jen vytvořit repozitář, ale v tomto kurzu se sním už nesetkáte :-).

Co budete používat hlavně, je příkaz svn.

Krokem číslo 2 bude vytvoření adresáře v rámci repozitáře, do kterého vložíte projekt. K práci se soubory v repozitáři musíte používat přikaz svn. Soubory v repozitáři jsou totiž komprimované a navíc, jak budete přidávat, měnit a odstraňovat soubory a adresáře, budou se ukládat do repozitáře pouze změny (ne celý projekt). Příkazy svn jsou naštěstí dost podobné příkazům linuxové příkazové řádky, takže si na ně rychle zvyknete.

Jak už jsem psal, k SVN můžete přistupovat lokálně, nebo přes internet. Pokud přistupujete lokálně, musíte příkazu svn říct cestu k repozitáři absolutní cestou, která začíná na file:///. Teď záleží na tom, kde máte uložený repozitář. Já si jeho obsah mohu vypsat pomocí následujícího příkazu:

Tentokrát se nevypíše nic, protože ještě v repozitáři znamky nic není.

Vytvořím si tedy adresář trunk. Adresář trunk se běžně používá pro název hlavní větve projektu. O tom, co jsou to větve a k čemu jsou dobré bude řeč později. Teď mi věřte, že trunk je ten jediný správný název :-).

Tadáá, máte svojí první verzi projektu. Text argumentu -m "..." je zpráva, která se uloží spolu s ukládanou verzí. Kdykoliv přidáváte nějakou novou verzi, SVN po vás chce komentář. Pokud byste -m neuvedli, otevře se vám editor, do kterého můžete komentář zapsat (to se hodí pro delší, víceřádkové komentáře).

Stažení projektu

Teď máte repozitář s projektem a s větví trunk. Abyste s projektem mohli pracovat, musíte si ho stáhnout do nějaké pracovní kopie. K tomu se používá svn checkdout.

Pracovních kopií si můžete udělat kolik chcete. Pro začátek udělám jednu. A udělám jí v adresáři znamky4.01. Za chvilku uvidíte proč.

Pro některé příkazy poskytuje svn zkratky, například místo checkout stačí napsat co.

Příkaz svn co má jako argument cestu k repozitáři a adresář, kam se má trunk stáhnout. Tím je tečka, tj. aktuální adresář.

V aktuálním adresáři teď najdete adresář .svn. To je všechno, co odlišuje pracovní kopii SVN od neverzované kopie projektu.

Adresáře .svn a jeho obsahu si nemusíte více všímat.

Vložení souborů do projektu

Příkazem svn status se můžete podívat na to, v jakém stavu je váš projekt (předpokládám, že jste v adresáři pracovní kopie, tj. v adresáři znamky4.01).

Příkaz vypsal všechny soubory, které se liší od poslední uložené verze/revize. Protože poslední revize je prázdný adresář (trunk), vypsali se všechny soubory. Otazník na začátku znamená „tento soubor neznám“.

Pro SVN neznámé soubory a adresáře označíte k verzování příkazem svn add.

Z výpisu je vidět, že se přidali (A) všechny soubory, včteně souborů v adresářích. Hvězdička v příkazu funguje tak, jak je v příkazovém řádku obvyklé – nahrazuje všechny soubory. Můžete samozřejmě přidávat jeden soubor za druhým jejich vyjmenováním, tj. něco jako svn add create-gdbm.sh curses.c statistika ….

Soubor znamky je binární soubor, tj. SVN v něm nedokáže zobrazit změny řádek po řádce.
Je to zkompilovaný program, který jsem přidal do SVN omylem. Zkompilovaný program verzovat nepotřebuji, tak ho smažu. Co nato SVN?

SVN píše, že je něco v nepořádku (!) a že se soubor znamky změnil (M). Smazání je taky změna :-). V nepořádku je proto, protože jsem ho smazal příkazem rm, a ne pomocí svn. To neva, to pořád moho napravit.

Prozatím jsem nic neodeslal do repozitáře, takže smazaný soubor znamky je navždy ztracen.

Podívejte se, jak by vypadalo, kdybych použil svn. V příkladu vytvořím prázdný soubor znamky (příkazem touch), přidám ho do SVN a zase smažu.

A chyba je tu. SVN si stěžuje, že chci smazat soubor, který má lokální modifikace (nový soubor se považuje za celý zmondifikovaný) a proto ho odmítne smazat, dokud modifikace nepošlete do repozitáře. Když si ale jste jistí, že modifikace chcete nadobro ztratit, můžete použít přepínač --force.

A teď konečně odešlu všechno do repozitáře příkazem svn commit.

Hurá. Vytvořil jsem revizi 2. Jak vidíte, číslo revize stoupá při každé změne v repozitáři (První revize byla vytvoření adresáře trunk). Příkaz svn status už nic nevypíše, protože jsou teď všechny soubory v pracovním adresáři schodné s tím, co je v repozitáři.

Práce se soubory

svn nabízí několik příkazů pro práci se soubory, které byste měli používat. Můžete je používat jak v pracovním adresáři, tak přímo v repozitory!

svn del

Smazání souboru. Ten už znáte.

svn mkdir

Vytvoření adresáře. Vzpomínáte na vytváření adresáře trunk?. To byl příklad použití příkazu přímo v repozitáři.

svn copy

Kopírování souborů. Subversion si bude pamatovat, že nový soubor pochází z toho původního (bude udržovat jeho historii). Pokud byste zkopírovali soubor bez svn a pak ho přidali do repozitáře, subversion by o tuto informaci přišlo.

svn mv

Přesun souborů a adresářů.

Řekněme, že se rozhodnu vytvořit soubor README. Něco do něj zapíšu a pošlu ho do repozitáře.

Teď jsem si ale vzpoměl, že by bylo lepší ho pojmenovat README.txt

Příkaz svn move se tváří, jako by přidal README.txt a smazal README, ale svn status ho usvědčuje, že si i zapamatoval, že soubor README.txt pochází z README (znak plus vedle A říká, že jde o přidání nového soubor, který má ale navíc nějakou historii).

Slučování změn

Teď ukáži, co se stane, když měníte jeden soubor v různých praconvích kopiích. Pro začátek si vytvořím novou pracovní kopii v adresáři Windows.

Stáhla se mi poslední verze projektu. Teď se rozhodnu upravit soubor statistika/kreditu.c a smazat z něj nepoužívanou proměnnou nacteno.

Vidíte, že je soubor modifikovaný (M). Co se v něm ale změnilo? Na to vám odpoví příkaz svn diff.

Nechal jsem si vypsat všechny změny z adresáře statistika. Změněná je jen jedna řádka v jednom souboru. Řádka začíná mínusem, jako že je smazaná. Kromě toho je vypsáno několik řádek nad a po, abyste se lépe zorientovali.
@@ -8,7 +8,6 @@ říká, že výpis začíná na řádku 8 a zobrazuje 7 řádků pro revizi 4, tj. tu z repozitáře a pro pracovní kopii (working copy) začíná také na řádku 8, ale vypisuje jen 6 řádek (nepočítá se ta řádka s mínus).

Teď se ještě rozhodnu změnit něco v souboru README.txt. Podtrhnu nadpisy Popis a Instalace. Nadpis Instalace ještě odsadím o řádek.

Tentokrát jsem řádky jen přidával, takže vidíte jen řádky s plusem …

Je na čase práci uložit do repozitáře.

Teď se přesunu do druhé pracovní kopie a rozhodnu se aktualizovat adresář statistika/

No vida, soubor statistika/kreditu.c se updatoval (U). (Neupdatoval se ale soubor README.txt, protože ten není v adresáři statistika.)

Konflikty

Protože jsem ale zapoměl, že jsem už nadpisy v README.txt podtrhal (nebo tu změnu udělal jakože nějaký můj kolega, co semnou na programu spolupracuje a já o ní nevím), udělám podtržení znovu. Místo teček ale podtrhnu nadpisy pomocí hvězdiček. Nadpis Instalace jsem také odsadil o jeden řádek.

Ajaj, soubor se nepodařilo odeslat. Nemůžete poslat do repozitáře soubor, který změnil už někdo jiný. Takže si nejdřív stáhnu aktuální verzi z repozitáře pomocí svn update.

Ajaj, další problém. SVN zjistil konflikt. Tj změny, které jsem udělal v README.txt a změny, které byli v repozitáři jsou na stené řádce a SVN nedokáže rozhodnout, co z toho je platný. Dává mi na výběr několik možností. Vybral jsem si p jako postpone, tj. odložení řešení problému na později.

Soubor README.txt je teď v konfliktu (C). Subversion vytvořil několik jeho kopií, README.txt.mine je kopie souboru, který jste měli v pracovní adresáři. README.txt.r4 je kopie souboru, který jste naposledy stáhli (tj vezre naposledy stažená do vašeho pracovního adresáře) a README.txt.r5, cože je kopie verze, kterou jste se snažili stáhnout teď.

Soubor README.txt obsahuje teď něco takového:

Popis
<<<<<<< .mine
*****
=======
.....
>>>>>>> .r5

Tento program je určen (nejen) pro studenty vysokých škol. Ukáže Vám, jak
poctivě studujete. Zaznamenáte si do něj své předměty a on vám na oplátku
spočítá vážený průměr, kolik trojek vám chybí do hranice 2.5 a kolik
kreditů jste již získali za semestr.
Zvýrazňuje předměty, u nichž jste ještě zkoušku neudělali, můžete si
vyhledávat předměty dle názvu nebo kódu (viz. obrázek) atd.

Instalace
<<<<<<< .mine
*********
=======
.........
>>>>>>> .r5

Program je …

Všechny řádky, které nedokázal svn sloužit jsou označeny pomocí <<<<<<< a >>>>>>>.

Po >>>>>>> .mine následují konfliktní řádky (v příkladu jen jeden řádek s hvězdičkama), pak =======, pak řádky z revize, kterou jsem se snažil aktualizovat a pak >>>>>>> .r5.

Teď je na mě, abych upravil soubor do stavu, který mi vyhovuje. Řekněme, že chci ponechat podtržení s hvězdičkami, tak všechno výše zmíněné smažu a nechám jen hvězdičky.

README.txt je ale stále ve stavu konfliktu, tak musím svn říct, že už jsem problém vyřešil (příkazem svn resolved).

Cestování časem

Příkaz svn log zobrazí uložené revize s popisem. S přepínačem -v zobrazí i soubory, keré se změnili.

Ale co to? Že bych měl jen jednu revizi? Subversion umožňuje, abyste měli v pracovní kopii různé verze souborů. Proto se po odeslání (commitu) automaticky nestáhne nejnovější verze celého adresáře. Takže je to potřeba udělat ručně.

Zdánlivě se nic nestalo (nezměnil se žádný soubor), ale teď už je celý pracovní adresář v revizi 6 a podle toho se bude chovat i svn log. Parametrem -l 3 jsem omezil výpis na poslední 3 revize.

Za domácí úkol vyzkoušejte svn log -v README.txt. Hádejte, zobrazí se vám i historie souboru README, ze kterého README.txt vzešel? Následující příklad napoví.

Další cestování v čase umožňuje příkaz svn diff. Můžete si zobrazit rozdíl v souborech v libovolných verzích.

Nechal jsem si zobrazit rozdíl mezi 3 a 6 verzí. Z výpisu vidíte, že verze 6 má oproti verzi 3 navíc podtržené nadpisy hvězdičkami. Mezi těmito verzemi je ještě verze s podtržením tečkami, ale já chtěl jen rozdíl verzí 3 a 6.

A nejlepší na konec. Příkazem svn up s volbou -r si mohu stáhnou z repozitáře libovolnou verzi dokumentu, nebo i celého adresáře. Jak vypadal můj projekt po druhém commitu?

Soubor README.txt tehdy ještě neexistoval (ani README). Vrátili se i změny provedené v souboru statistika/kreditu.c. A teď zase z5 na aktuální verzi.

Větve (branches) a tagy

Teď už umíte všechno co je potřeba k tomu, abyste mohli subversion používat. Pokud ale chcete, můžete číst dále :-).

Už víte, že si můžete zkopírovat celý projekt do jiného adresáře v repozitáři. Tím vytvoříte tzv. větev (branch). K čemu je to dobré? Můžete pracovat v této jiné větvi na nějakém úkolu, aniž byste ovlivnili hlavní větev (trunk). Na hlavní větvi mezi tím může váš kolega provádět jiné změny, aniž byste mu narušoval práci svými změnami. Pokud se vám změny líbí, můžete je snadno sloučit do hlavní větve (merge). Pokud se vám nelíbí, prostě větev smažete.

Než ukážu typický proces větvení, ještě se zmíním o tagování. Tag se používá k nějakému lidskému označení revize. Když se rozhodnete zveřejnit novou verzi svého programu, většinou ho nějak pojmenujete a dáte mu číslo verze (ale asi jiné, než používá subversion).

Subversion žádný speciální nástroj pro tagování nemá, místo toho existuje taková „nepsaná“ dohoda, že se tagování provádí kopií projektu do adresáře tags.

Větve, ve kterých chcete něco měnit, se ukládají do adresáře branches. Jedná se zase o „nepsanou“ dohodu, ale rozhodně doporučuji se tohoto postupu držet. Některé nástroje, které umí s SVN pracovat, na tento způsob pojmenování větví a tagů spoléhá.

Teď si otaguji aktuální větev. Je na čase vydat verzi znamky4.02 :-) Kopii můžu udělat rovnou v repozitáři.

Protože jsem v adresáři znamky4.01, mohu si dovolit použít zkrácený zápis k repozitáři pomocí stříšky ^. Stříška se nahradí plnou cestou k repozitáři file:///home/petr/resource/c/linux/zdrojaky-linux/11subversion/var/svn/znamky/.

^/tags/znamky4.02/ je vlastně také větev. Ale tuto větev byste už nikdy neměli měnit. Je tu přece jako odraz stavu toho, co jste zveřejnili lidem.

Teď budu pokračovat ve vývoji hlavní větve (trunk), kterou mám pořád v pracovní kopii. Upravím například soubor Makefile, aby příkazy rm měli argument -f a v souboru curses.h změním knihovnu ze staré <curses.h> na novou <ncurses/curses.h>. A změny odešlu do SVN.

Ale moment! Teď mi došlo, že jsem zapoměl změnit číslo verze v souborech README.txt a struktury.h, takže ve verzi 4.02 je pořád zapsáno 4.01. Jak už jsem psal, jednou vydaná verze by se neměla měnit. Jako že jsem ale naštěstí ještě nic nezveřejnil, takže si to můžu dovolit.

Potřebuju nějak upravit větev ^tags/znamky4.02. Mohou si ji pomocí svn checkout celou stáhnout, ale mám i lepší možnost – pomocí svn switch se do ní „přepnout“. Příkazem svn info se pak můžete podívat, s jakou větví pracujete.

Tak jednoduché a rychlé to bylo! Jen 2 soubory se změnili a už pracuji v jiné větvi :-).

Teď provedu požadované změny a odešlu je.

Tak mě napadlo, co kdybych, ještě než 4.02 zveřejním, přenesl změny z hlavní větve? Není problém, trochu si zamergeujeme …

Nojo, zase jsem neupdatoval a tak mám soubory v různé verzi (viz svn st- v). To se dá snadno napravit.

Subversion ví, v jaké revizi se větev znamky4.02 oddělila od větve trunk a přenese změny od tohoto okamžiku (r9) až k té poslední (r11). Navíc zapíše do adresáře (.) informaci o provedeném merge, takže při příštím merge přenese změny od r11 dále. Změny se teď zapsali do vaší pracovní kopie, takže je ještě potřeba poslat je na server.

Teď se můžu vrátit zpět k větvi trunk.

Tak mě napadlo, nešlo by přenést změny z znamky4.01 do trunk? Jasně že šlo. A navíc chci přenést jen změnu s číslem verzí. To taky není problém.

Z výpisu se dočtu, že mě zajímá rozdíl mezi revizí 9 a 11.

Příkazy svn st a svn diff si můžete prohlédnout mergnuté změny a pak je odeslat příkazem svn commit. To už vám nechám za domácí úkol.

Celý proces větvení a mergování z této kapitoly jsem se pokusil znázornil na obrázku:

Větvení

Tak jste viděli, jak pracovat s větvemi, jak mezi nimi přepínat a jak přenášet změny z jedné větve do druhé.

Máte už docela slušné základy SVN, ale je toho pořád hodně co nevíte. Nevíte třeba, jak označit některé soubory, aby je SVN ignorovalo (a neverzovalo). Nevíte, jak pracovat se repozitářem na jiném stroji (přes HTTP nebo SSH) a nevíte spoustu dalších drobností. Všechno si můžete nastudovat na svnbook.red-bean.com/. Můžete také použít příkaz svn help pro zobrazení nápovědy. Doufám, že od teď už budou všechny vaše projekty pod dohledem nějakého verzovacím systému.