- předchozí článek - následující článek - obsah - úvodní stránka -

Linuxové noviny 03-04/2001

Správa projektů pomocí CVS

Miloslav Ponkrác, 29. ledna 2001

Úvod

Pokud to myslíte s prací na nějakém projektu opravdu vážně, po nějaké době začnete pociťovat potřebu nějakého programu, který vám v něm udělá pořádek. Program, který zařídí, abyste si nejnovější verzi nějakého textu, programu, obrázku, či čehokoli jiného nepřepsali starší verzí. Snad každý takto přišel občas o práci, která mu zabrala dlouhý čas. Kromě toho se občas stane, že naopak zjistíte, že byste se potřebovali vrátit ke starší verzi, protože čas ukázal, že je lepší, než novější. Ale co s tím? Schraňovat mnoho starých verzí, kdyby náhodou? A to už vůbec nemluvím o tom, pokud byste na projektu měli dělat dva, či vás budou pracovat desítky lidí na tom samém projektu. Jak potom zabránit zmatku?

Protože tyto problémy měli lidé již dlouho, začaly vznikat různé programy na správu projektů. A tento článek by měl být o léty prověřeném programu, který sám používám, a který si nemohu vynachválit. Jedná se o CVS, což je anglická zkratka Concurrent Versions System. Tento systém má za sebou dlouhý vývoj, je k dispozici na většinu platforem, mimo jiné i na Windows, Linux, OS/2 a mnohé další. Tímto systémem byly řízeny mnohé projekty. A to nejlepší nakonec, přes jeho nesporné kvality je zcela zadarmo, můžete si ho stáhnout na stránkách CVS.

Snad jenom upozornění, tento dokument je psán tak, že pokud chcete začít pracovat se systémem CVS, anebo ho jenom vyzkoušet, nemusíte ho číst celý. Následující kapitoly vás provedou krok za krokem nejnutnějšími kroky, které musíte udělat. Začínám tím, kde program cvs získat, jak ho nainstalovat, jak vytvořit nový projekt, a jak v něm spravovat váš první projekt. Pokud chcete systém CVS používat opravdu jen na nejjednodušší správu projektů, a pracujete na projektu sám, stačí vám toto nezbytné minimum. Pokud potřebujete spravovat projekt ve více lidech, bude nezbytné si přečíst ještě minimálně alespoň kapitolu o práci ve vícečlenném týmu. Zbylé kapitoly vám umožní používat systém CVS s lehkostí a jistotou.

Filozofie práce se systémem CVS

Tato kapitola o filozofii práce se systémem CVS zde původně nebyla. Vzhledem ke zkušenostem s lidmi, kteří začali používat CVS podle tohoto dokumentu jsem později zjistil, že patří mezi nejdůležitější. Proto vás prosím, přečtěte si tuto kapitolu důkladně. Velice vám usnadní pochopení dalšího textu.

První je potřeba pochopit, že systém CVS slouží jako systém, který dohlíží na skupinu souborů nazývaných projekt. Systém CVS je schopen udržet pořádek v této skupině souborů a nejenom to. Umožní vám, abyste se třeba kdykoli vrátili ke starší verzi. Není třeba problém chtít po CVS, aby mi nahrál do adresáře stav projektu třeba 1. ledna 1999 o půlnoci. Umožní vám, aby do skupiny souborů (projektu) dělalo zásahy a změny více lidí. Je možné například vyvíjet souběžně více verzí, což je často potřeba. Představte si třeba, že vyvíjíte informační systém, který jste v první verzi dodali zákazníkovi. Mezitím začnete vyvíjet druhou verzi informačního systému. Poté zákazník objeví několik chyb v první verzi, a požaduje opravu. Je jasné, že mu nedáte nestabilní druhou verzi, která se teprve vyvíjí (tedy jste-li profesionálové), ale uděláte opravy nad první verzí. A nyní tu máte souběžně dvě větve projektu. Jedna vede k vývoji stabilní odladěné první verze, a druhá k vývoji zatím nedokončené druhé verze. A systém CVS toho dokáže daleko více.

Na druhé straně je potřeba pochopit, že systém CVS je především systém správy různých verzí souborů. Je zbytečné od něj chtít například přeložit hotový program, na to existují jiné nástroje. Ale určitě vám zaručí, že v programu vám nevzniknou chyby jenom proto, že někdo přeložil starší modul. Systém CVS také neprovádí testování programu, ani nenahrazuje vedoucího projektu.

V systému CVS se pracuje na několika úrovních. Přesněji řečeno, práce se systémem CVS je myšleně rozdělena do několika celkem oddělených kategorií. V zásadě jde o vytvoření nového projektu, administrace projektu, a potom akce, které umožňují rutinní práce. Rutinní prací myslím získání aktuální verze (případně jiné) verze projektu, a poté nahrání nové verze do systému CVS.

Kde získat systém CVS

Při používání systému CVS si můžete vybrat, zda budete s tímto systémem komunikovat pomocí příkazové řádky, a nebo pomocí grafického rozhraní. Je také možné obojí kombinovat.

V době, kdy píši tento text, se zdá, že CVS je spravováno na stránkách cvshome.org. Soubory, které jsou potřeba pro správu CVS pomocí příkazové řádky, lze stáhnout z FTP serveru. Zde si vyhledejte svůj operační systém (nejčastěji asi Windows, nebo Linux) a stáhněte si poslední stabilní verzi. Konkrétně poslední binární verze pro Windows ke stažení je verze 1.10, kterou lze stáhnout jako soubor cvs-1.10-win.zip. Tento soubor obsahuje vše, co budete potřebovat. Pokud používáte Linux, či jiný systém, najděte si příslušný podadresář, a řiďte se zvyklostmi vašeho operačního systému.

Pokud chcete spravovat CVS pomocí grafického prostředí, potom existuje vícero systémů, jejichž popis není součástí tohoto manuálu (alespoň s tím zatím nepočítám). Tuším, že grafické prostředí v pozadí volá CVS s příkazovou řádkou.

Vyzkoušel jsem WinCVS pro Windows, který je velice pěkně udělaný. Pokud chcete WinCVS používat, jeho součástí je i balík pro práci s příkazovou řádkou, i když jej nemusíte používat. WinCVS všude upozorňuje, že není zaručena funkčnost s Windows 95, na této verzi Windows je potřeba instalovat nějaké novější DLL. Moje krátkodobé zkušenosti s WinCVS říkají, že pro zvládnutí základní práce s CVS potřebujete prakticky stejné znalosti, jako pro práci s příkazovou řádkou. Nečekejte proto, že sednete ke grafické nadstavbě a budete okamžitě spravovat projekty, pokud nemáte s CVS žádné zkušenosti. Síla grafické nadstavby se projeví spíše v pokročilejších funkcích, složitější akce provedete rychleji a jednodušeji. A hlavně je to otázka, zda dáváte přednost klikání, nebo příkazové řádce. Pokud vám vyhovuje grafické prostředí více, tak jděte do toho.

V dalším textu budu předpokládat, že budete ovládat systém CVS pomocí příkazové řádky. Jednak je toto ovládání jednotné, a přitom nijak složité a umožňuje vám přitom plnou kontrolu nad systémem. Ovládání pomocí grafické nadstavby se liší podle platformy, na které budete systém používat, a také podle použité grafické nadstavby.

Instalace systému CVS

Jak tedy začít? Stáhněte si tedy nejdříve CVS, viz předchozí kapitola. Získaný soubor umístěte na disk. Pro Windows neprobíhá žádná instalace, pouze soubory ze zazipovaného archivu rozbalíte do vámi zvoleného adresáře kamkoli na disk. Pro ukázku budu v dalším textu předpokládat, že jste umístili cvs do adresáře c:\cvs (v případě Windows), případně /usr/bin (v případě Unixu).

Nyní je potřeba zvolit adresář, ve kterém si bude CVS systém uchovávat informace o projektech. Je lépe zvolit jiný adresář, než ve kterém je umístěn vlastní program cvs. Volba umístění adresáře závisí na tom, jakým způsobem budete chtít projekty řídit. Pokud chcete řídit projekty vlastní, asi nejlepší je zvolit adresář na vašem lokálním disku. Pokud chcete řídit vývoj projektů ve Vaší firmě, je dobré umístit jej na server Vaší lokální sítě. A pokud chcete vyvíjet například společný projekt po Internetu, je vhodné jej umístit na FTP server. Důležité je, aby všichni, kdo se účastní na projektu, mohli z tohoto adresáře číst i zapisovat. Jsou samozřejmě možné i jiné varianty, například adresář s informacemi o projektech může mít na svém lokálním disku vedoucí projektu, a lidé, kteří se účastní projektu si čas od času přijdou nahrát do systému CVS svoji práci a odnést si změny, které provedli druzí. Je možnost zvolit mnoho jiných variant. Je potřebné se také zamýšlet nad otázkou bezpečnosti. Pokud například nechcete povolit přístup k projektu nepovolaným, je potřeba jej neumísťovat na veřejném FTP serveru, v lokální síti by do adresáře s informacemi o projektu neměli mít přístup nepovolaní, apod.

Pro počáteční vyzkoušení systému CVS je asi nejlepší umístit adresář s informacemi na lokální disk. Zvolíme tedy adresář pro data. Pro Unix jej v rámci ukázky zvolím asi jako $HOME/cvsroot, pro Windows třeba jako c:\cvsroot. Pro instalaci je potřeba udělat ještě dvě akce, a to přidat program cvs do cesty pomocí proměnné PATH, abychom mohli program cvs spouštět z jakéhokoli adresáře. A nastavit proměnnou CVSROOT, ve které bude zapsána plná cesta k adresáři pro data systému CVS.

Nejlepší cesta, jak nastavit obě proměnné, je v případě Windows zapsat je do souboru AUTOEXEC.BAT, v případě Unixu do .profile. Úpravy v AUTOEXEC.BAT (pro Windows): Na konec souboru AUTOEXEC.BAT přidat následující dva řádky. Poté uložit a restartovat.

set CVSROOT=:local:c:\cvsroot
set PATH=c:\cvs;%PATH%

Úpravy pro Unix ponechám na váženém čtenáři.

V této chvíli je tedy potřeba vytvořit adresář pro data programu. Jde jenom o to, že adresář c:\cvsroot (pro Windows), případně $HOME/cvsroot (v případě Unixu) musí existovat. Pokud neexistuje, vytvoříme ho, ať už pomocí příkazu mkdir (pracuje jak ve Windows, tak v Unixu), a nebo jinak. Máme tedy vytvořen prázdný adresář pro data projektu.

Teď je nutné inicializovat adresář pro data. To slouží k tomu, aby si systém CVS vytvořil potřebné soubory pro správu projektů. Provádí se to příkazem cvs init. V této chvíli máme systém CVS připravený k používání.

Založení prvního projektu v systému CVS

V této chvíli máme systém CVS připravený ke správě libovolného množství projektů. Dále je potřeba do něj jednotlivé projekty "nasázet". Systém CVS můžete použít ke správě například tvorby vašeho Webu, k řízení programátorského projektu, či jiného projektu. Záleží na tom, co potřebujete. Předem je ale potřeba říci, že se jedná o systém ke správě verzí. Dokáže tedy velmi dobře udržovat pořádek v různých verzích, i když na projektu pracuje mnoho lidí, ale rozhodně není určen pro překládání programů do binární podoby apod.

Předpokládejme tedy, že budeme vytvářet webovskou stránku. Tento projekt si nějak pojmenujeme, například "prvniprojekt". Vytvoříme si někde adresář, který si může jmenovat naprosto jakkoliv. Jméno adresáře dokonce nemusí mít vůbec nic společného s názvem projektu, jenom do něj překopírujeme vše, co již na tomto projektu máme hotovo. Pokud začínáme, a nemáme zatím nic, nechme adresář prázdný. Důležité je, aby v tomto adresáři byly pouze soubory, které se týkají našeho projektu. Soubory mohou být rozdělené do podadresářů. Pro začátek doporučuji, aby se jednalo pouze o textové soubory (tedy texty, HTML stránky, zdrojové kódy programů, skripty apod.). Ostatní soubory zatím do adresáře neumisťujte, přidáme je později, potřebují trochu odlišný způsob. Zadání projektu prvniprojekt do systému CVS provedeme ve dvou krocích:

1. Přesuneme se do adresáře, kde je vše co patří k projektu. Jak již bylo napsáno výše, pokud začínáme s projektem, může se jednat i o prázdný adresář.

2. Z tohoto adresáře spustíme příkaz:

cvs import -m "zalozeni projektu" prvniprojekt poc-tym poc-verze

Vysvětlím, co znamenají podrobněji části výše uvedeného příkazu. Slovo import znamená příkaz, který systém CVS vyzývá k založení nového projektu. Zároveň mu říká, aby do tohoto projektu zavedl všechny soubory, které objeví v aktuálním adresáři (zjistíte příkazem cd ve Windows, případně pwd v Unixu). Do projektu se také přidají všechny podadresáře, a soubory v těchto podadresářích. Volba -m říká systému CVS, že chceme připsat poznámku, která je uvedena v uvozovkách za touto volbou. Musím podotknout, že poznámku v tomto případě systém CVS vyžaduje, a pokud mu ji nezadáte volbou -m v příkazovém řádku, systém CVS spustí editor, kde mu ji můžete zadat. Slovo prvniprojekt je název projektu. Další dvě slova značí jméno týmu a jméno počáteční verze, tam můžete zadat cokoli, třeba zrovna "poc-tym", nebo "poc-verze".

Pokud jste se dostali až sem, a spustili příkaz, obvykle vám systém CVS nejdříve ukáže průběh načítání souborů do projektu, a potom napíše něco v tom smyslu, že "No conflicts" a ještě něco dalšího. Založili jste úspěšně projekt do systému CVS.

Teď bude dobré smazat adresář, ze kterého jsme spustili CVS, a zkopírovali soubory patřící k projektu. Protože zatím se systémem začínáte, nezapomeňte si soubory zálohovat! Systém CVS je prověřený a celkem spolehlivý, ale je potřeba s ním umět pracovat.

Správa prvního projektu v systému CVS

Máme tedy první projekt uložený v systému CVS. Kdykoli budeme chtít na projektu pracovat, přepneme se do adresáře, ve kterém chceme pracovat. V tomto adresáři spustíme příkaz:

 
cvs checkout prvniprojekt 

Tento příkaz udělal to, že vytvořil v pracovním adresáři podadresář prvniprojekt, a do něj nahrál aktuální verzi všech souborů. Kromě toho si do každého adresáře přidal podadresář CVS se svými údaji. Nyní můžete v souborech měnit, co se vám líbí. Opravovat chyby, dopisovat, zkrátka pracovat na projektu. Po skončení práce je potřeba vaše změny nahrát zpět do systému CVS, a to příkazem:

 
cvs commit -m "nejaka poznamka" 

Příkaz commit zaznamenává změny na projektu zpět do systému CVS. Teď se možná ptáte, co je na tom tak úžasné. Třeba to, že na projektu může pracovat více lidí najednou, a systém CVS si dokáže poradit i v případě, že více lidí změní stejný soubor. A nebo vám dokáže vytáhnout stav projektu, jaký byl v libovolné chvíli. Chcete získat stav souborů přesně tak, jako byl třeba 2. prosince? Není to problém. A to je jenom velice malá přehlídka jeho možností. Nikdy žádnou změnu neztratí, a přitom zbytečně neplýtvá diskovým prostorem. Ukládá si totiž pouze změny od předchozí verze, takže jeho data o projektu zabírají poměrně málo místa na disku.

Nutno říci, že příkaz commit je daleko flexibilnější, než bylo uvedeno. Můžete například uložit změny pouze jednoho souboru:

cvs commit -m "nejaka poznamka" jmeno_souboru

Při používání příkazu commit zjistíte, že systém CVS kontroluje pouze soubory, které tam už byly při zakládání projektu. V pracovním adresáři si tedy můžete vytvořit spousty souborů, ale systém CVS si všimne jenom těch, které tam byly od počátku. Pokud potřebujete přidat nový soubor do systému CVS, použijte příkaz spuštěný z pracovního adresáře:

cvs add -m "nejaka poznamka" jmeno_souboru

Systém CVS pracuje se skupinou souborů nazývaných projektem, jak už bylo řečeno výše. Každý soubor, který má být součástí projektu je nutné zaregistrovat, aby CVS věděl, že má hlídat změny i tohoto souboru. To se provádí dvěma způsoby. Prvním je příkaz import, který provede vytvoření nového projektu v systému CVS, a zároveň zaregistruje všechny soubory v aktuálním adresáři i jeho podadresářích. Příkaz import je určen ke kompletnímu vytvoření projektu, to znamená, že navíc všechny soubory nahraje do projektu.

Pokud již máme projekt v systému CVS vytvořený, používá se druhý způsob, a to příkaz add. Tento příkaz zařídí, že systém CVS bere na vědomí, že součástí projektu se stal další soubor, a nic víc! To znamená, že aktuální verze nového souboru není nahrána do systému CVS! To se provede až dalším příkazem, který slouží k nahrávání změněných souborů do systému CVS, a tím je commit. Tedy ještě jednou: po použití příkazu add si systém CVS pouze poznamená, že od této chvíle bude součástí projektu i nově zadaný soubor. Tento soubor si ale nenahraje do systému CVS, protože by v tom byl zmatek. Jediný příkaz, který umožňuje nahrávat změny souborů do systému CVS, je příkaz commit. Proto vám příkaz add vypíše (v angličtině) zprávu, že si poznamenal, že soubor patří do projektu, ale počká si na příkaz commit, který tento soubor nahraje do systému. A poté již bude automaticky nahrávat i změny v novém souboru od všech lidí, kteří pracují na projektu.

Teď již tedy víte, že každý nový soubor je potřeba do projektu zaregistrovat. Dát prostě systému na vědomí, aby nový soubor také považoval za součást projektu. Při registrování je potřeba upozornit na dvě důležité skutečnosti. Za prvé, pokud vytvoříte nový podadresář v projektu, je potřeba ho také zaregistrovat pomocí příkazu add. Provádí se to úplně stejně, jako kdyby to byl soubor. A až potom je možné zaregistrovat soubory v tomto podadresáři. Pokud tedy v pracovním adresáři založíme nový podadresář, a v něm nový soubor, je potřeba nejdříve přidat do systému CVS podadresář, a až poté nový soubor. Podadresář se přidává úplně stejně jako soubor, jenom místo jména souboru uvedeme jméno adresáře.

Druhou důležitou skutečností je to, že musíte dát systému CVS na vědomí, co je čistý textový soubor, a co je binární soubor. Binárním souborem se rozumí například obrázky, dokumenty Office, i když je to z Wordu, apod. Pokud se jedná o čistý text, nic zvláštního se neděje, pokud budete pracovat s binárními soubory, je nutné při registraci tohoto souboru dát systému CVS na vědomí, že to není čistý text! V takovém případě je při registrování pomocí příkazu add nutné použít volbu -kb. V textových souborech totiž provádí CVS určité optimalizace. Příkaz na přidání binárních souborů vypadá tedy takto:

cvs add -kb -m "nejaka poznamka" jmeno_souboru

Pokud přidáte binární soubor, například obrázek, aniž byste systému CVS sdělili, že se nejedná o čistý text, systém CVS takový soubor zdeformuje. Je tedy potřeba si na toto dávat pozor. Pokud čistě náhodou na to zapomenete, a přidáte binární soubor bez volby -kb, tak se to dá opravit následujícím způsobem:

  • Zazálohujete si soubor z pracovního adresáře, který chcete označit jako binární. Je to proto, že v průběhu této akce se soubor zdeformuje a bude potřeba ho obnovit. Pokud je i v pracovním adresáři soubor zdeformovaný (to se stane, pokud jste předtím použili příkaz update), potom je potřeba někde mít čistou, nezdeformovanou verzi souboru, kterou použijete v pátém kroku pro obnovení souboru.
  • Provedete příkaz: cvs admin -kb jmeno_souboru. Tento příkaz říká, že soubor jmeno_souboru bude od této chvíle označen v databázi systému CVS (tzv. repository) jako binární, a CVS s ním takto bude zacházet.
  • Provedete příkaz: cvs update jmeno_souboru. Příkaz update slouží k tomu, aby si CVS upravil ve vašem pracovním adresáři své vnitřní záznamy o souboru. Ve druhém kroku jste totiž označili soubor jako binární v repository, ale nikoli ve vašem pracovním adresáři. Tento třetí krok proto přenese označení na binární soubor i do vašeho pracovního adresáře. Pokud tento třetí krok neprovedete, tak Vás bude CVS upozorňovat na chybu.
  • Třetí krok jako vedlejší efekt nahrál do pracovního adresáře zdeformovaný soubor. Proto je potřeba jako další krok nahrát ze zálohy dobrou, nezdeformovanou verzi souboru.
  • Jako poslední krok nahrajeme do systému CVS (do jeho databáze, čili repository) správnou verzi z pracovního adresáře. To se provádí již známým příkazem commit: cvs commit -m "oprava na binární verzi" jmeno_souboru.

Někdy se naopak stane, že potřebujeme nějaký soubor vymazat z projektu. Potom se nám hodí příkaz remove:

cvs remove jmeno_souboru

A opět je potřeba zdůraznit, že příkaz remove nedělá nic jiného, než odregistrovává soubor z projektu. Říká tedy, že soubor přestal být součástí projektu, a systém CVS nebude již dále zaznamenávat změny v tomto souboru. Samozřejmě, že pokud budete chtít vytáhnout ze systému CVS verzi z doby, dokud byl tento soubor součástí projektu, tak ho tam systém CVS přidá, ale ve verzích nahraných do CVS po použití příkazu remove ho přestávají zajímat změny na odregistrovaném souboru.

Příkaz remove nikde nic nemaže, a v pracovním adresáři vám vše nechá v původním stavu. Ale pro úspěšný průběh příkazu remove bude potřeba, aby odstraňovaný soubor v pracovním adresáři nebyl. Pokud budete chtít odstranit soubor, který je přítomný v pracovním adresáři, CVS nic neprovede, a pouze vám vypíše hlášení v anglickém jazyce. Proto je klasický postup pro mazání nejdříve smazat soubor z pracovního adresáře, a poté ho odstranit příkazem remove. Aby se nám nezauzlovaly prsty, pokud budeme rušit více souborů, nabízí CVS parametr -f. Ten provede navíc smazání souboru z pracovního adresáře, a udělá tedy oba kroky naráz:

 
cvs remove -f jmeno_souboru 

Toto je v zásadě to nejdůležitější, co potřebujete ke správě projektu pomocí systému CVS, zejména pokud ho spravujete sami. Další kapitoly se zabývají některými dalšími finesami systému CVS. Toto vám stačí, abyste si řídili svůj projekt sami doma. Další čtení vám umožňuje ze systému CVS získat více, nebo pracovat ve vícečlenném týmu, ale v zásadě pokud jste dočetli sem, jste schopni si řídit svůj vlastní projekt v jednočlenném týmu sami doma.

Výpisy změn v souborech - logy

V této kapitole si povíme něco o zjišťování změn v souborech uložených do systému CVS. Systém CVS ve svých manuálech nazývá prostor, ve kterém ukládá data, termínem repository.

Pokud jsme již soubor několikrát změnili, někdy bývá užitečné zjistit, jaké změny jsme provedli. Pokud jste již práci se systémem CVS zkusili, zjistili jste, že vás CVS nutí každou změnu okomentovat. Většina příkazů má možnost zadaní volby -m, za kterou následuje v uvozovkách poznámka. Pokud poznámku nezadáte, CVS spustí editor, abyste ji dopsali. Mírně ironicky by se dalo napsat, že vás "nevtíravým" způsobem nutí, abyste ke každé změně dopsali komentář, co jste to vlastně udělali.

Tyto komentáře mají svůj smysl, jsou totiž přístupné všem. Kromě toho CVS při každé změně zaznamenává datum a čas změny, kdo změnu provedl, zvýší automaticky číslo verze, a další údaje. Kromě toho umožňuje tyto údaje doplnit i do textu v souborech, které jsou součástí projektu.

Začneme tedy něčím jednoduchým. Jak zjistit celou historii změn nějakého souboru? Stačí na to následující příkaz:

cvs log jmeno_souboru

Příkaz log vypisuje všechny možné informace o souboru, který si CVS udržuje. Můžete si tam přečíst i zadané komentáře, kdo změny provedl (tedy ne že by tam bylo přímo jméno, ale objeví se tam přihlašovací jméno toho, kdo spustil cvs commit). Samozřejmostí jsou data, čas, apod. Snad jenom poznámku, příkaz log je možné spustit i bez udání jména souboru, potom vypíše informace o všech souborech, což je pěkně rozsáhlé.

Vzhledem k rozsahu logovacího výpisu i pro jeden soubor se většinou výstup ještě nějak upravuje. Buď se za příkaz připojí filtr more, který zajistí, že se text zastaví po každé obrazovce, a neodjede:

cvs log jmeno_souboru | more

Také je možné logovací výpis uložit do souboru:

cvs log jmeno_souboru > \
jmeno_souboru_pro_logovaci_vypis

Logovací výpisy můžeme řídit různými volbami. Jak si můžeme snadno ověřit, jsou logovací výpisy velmi rozsáhlé. Mnohdy potřebujeme pouze seznam souborů uložených v repository (tedy zaregistrovaných souborů a adresářů). Toho dosáhneme takto:

cvs log -R

Další volbou je zobrazit pouze změny souborů, které provedl určitý člověk. Předem je potřeba říci, že CVS ukládá s každou změnou provedenou pomocí příkazu commit automaticky i informaci, kdo změnu nahrál. Není to zde ale uloženo jako jméno a příjmení, ale CVS si zjistí, kdo je k počítači momentálně přihlášený, a zapíše si toto přihlašovací jméno. Pokud je potřeba zjistit, které všechny změny má na svědomí uživatel s přihlašovacím jménem sandokan, použijte:

cvs log -wsandokan jmeno_souboru

Jak je vidět z příkladu, použijete volbu -w, za kterou bez mezery následuje přímo přihlašovací jméno uživatele. Vynecháte-li jméno souboru, zobrazí se všechny změny v celém projektu.

Pokud vám vadí, že se vypisují i soubory v podadresářích, pomocí volby -l (malé písmeno L, nikoli číslice 1) zajistíte, že se budou vypisovat pouze soubory v aktuálním adresáři.

Velmi často Vás také zajímají změnu provedené v určitém čase, třeba za minulý měsíc (aby se vědělo, kdo si zaslouží prémie :-)), před dvěma týdny apod. K tomu je určena volba -d, která má velice bohaté možnosti. V následujících příkladech jsou některé z nich uvedeny:

  • cvs log -d "1 week ago"
  • vypíše změny provedené dříve, než minulý týden

  • cvs log -d "yesterday"
  • vypíše změny provedené dříve, než včera

  • cvs log -d "last month"
  • vypíše změny provedené dříve, než za poslední měsíc

  • cvs log -d "2 hours ago"
  • vypíše změny provedené dříve, než před dvěma hodinami

  • cvs log -d "1999/12/01"
  • vypíše změny provedené do 1. prosince 1999

  • cvs log -d "1999/12/01 12:43"
  • vypíše změny provedené do 1. prosince 1999 ve 12:43

  • cvs log -d "> 1 week ago"
  • vypíše změny provedené později, než před týdnem

  • cvs log -d ">= 2 hours ago"
  • vypíše změny provedené před dvěma hodinami, a nebo později

  • cvs log -d "1999/11/01 <= 1999/11/30"
  • vypíše změny provedené od 1. listopadu do 30. listopadu 1999

Výše uvedené informace lze kombinovat, takže například, chcete-li vědět, co všechno změnil uživatel s přihlašovacím jménem abcdefgh za poslední týden v současném adresáři, použijete:

cvs log -wabcdefgh -d ">= last week" -l

Automatické přidávání informací o verzi do souboru, nahrazování klíčových slov

Pokud vyvíjíme nějaký projekt, stane se někdy, že se ptáme, a jakou verzi souboru máš? To se dá zjistit pomocí data a času, ale není to ono. Jak tedy zajistit, aby v každém souboru byly napsány potřebné informace, třeba zrovna číslo verze? Nebo další údaje?

Systém CVS toto umožňuje pomocí klíčových slov. Pokud kamkoli do nějakého textového souboru, který je součástí projektu napíšete třeba:

$Date$

a nahrajete změny příkazem commit, zjistíte, že systém CVS vám do souboru přidal celé datum a čas poslední změny souboru:

$Date: 2000/01/09 17:58:58 $

Samozřejmě takových údajů je celá řada, a jsou vyjmenovány a popsány v následujícím seznamu:

  • $Author$ - přihlašovací jméno uživatele. CVS to nahradí zhruba takto: $Author: ponkrac $
  • $Date$ - datum a čas poslední změny souboru. Datum a čas je vypisován ve světovém čase, tedy v čase na nultém poledníku. To je také oficiálně používaný čas na Internetu, který je zvolen proto, aby nebyly problémy s posuny času na různých místech zeměkoule. CVS to nahradí zhruba takto: $Date: 2000/01/09 17:58:58 $
  • $Header$ - standardní hlavička, která obsahuje plnou cestu k souboru v repository, číslo verze, datum a čas na nultém poledníku, stav souboru, a pokud je soubor uzamčen, tak kdo ho uzamkl. CVS to nahradí za: $Header: d:\cvsroot/ponny_html/cvs_manual.html,v 1.30 1999/12/31 12:58:15 ponkrac Exp $
  • $Id$ - to samé, co $Header$, ale namísto plné cesty k souboru se vypisuje pouze jméno souboru. CVS to nahradí za: $Id: cvs_manual.html,v 1.30 1999/12/31 12:58:15 ponkrac Exp $
  • $Name$ - jméno značky (neboli tagu), pokud existuje. O značkách se můžete dočíst v jedné z dalších kapitol. CVS to nahradí za: $Name: jmeno_znacky $
  • $Locker$ - přihlašovací jméno toho, kdo uzamkl verzi, nebo nic, pokud soubory uzamčeny nejsou. Nutno říci, že uzamykání se málokdy používá. CVS to nahradí za: $Locker: sandokan $
  • $Log$ - vloží prakticky ty samé informace, které můžete získat příkazem log. CVS nahrazuje slovo rozsáhlým výpisem o poslední změně v souboru, takže následující příklad nahrazení je na více řádek:
    $Log: cvs_manual.html,v $
    Revision 2.11 2000/01/09 17:58:58 ponkrac
    prosel kontrolou spravnosti syntaxe
    Revision 1.30 1999/12/31 12:58:15 ponkrac
    podrobnejsi rozepsani klicovych slov
  • $RCSfile$ - jméno souboru v repository. CVS to nahradí za: $RCSfile: cvs_manual.html,v $
  • $Revision$ - číslo verze. CVS to nahradí za: $Revision: 2.11 $
  • $Source$ - jméno souboru v repository s plnou cestou. CVS to nahradí za: $Source: d:\cvsroot/ponny_html/cvs_manual.html,v $
  • $State$ - stav souboru ve zkratce, možné stavy souboru jsou Exp (experimentální verze), Stab (stabilní verze) a Rel (verze určená k distribuci). CVS to nahradí za: $State: Exp $

Asi nejčastěji se používá klíčové slovo $Id$. Rozepíšeme si jeho výstup podrobněji. Pokud do textu souboru dopíšeme toto slovo, učiníme tak do komentářů. Například v HTML souboru bude vypadat asi takto:

<HTML>
<!-- $Id$ -->
a tak dále

Pokud provedeme příkaz commit, objeví se rozvinutý text namísto $Id$:

<HTML>
<!-- $Id: cvs_manual.html,v 2.11\
 2000/01/09 17:58:58 ponkrac Exp $ -->
a tak dále

Zde vidíte všechny podstatné údaje o souboru přímo v něm. Vidíte, že soubor se jmenuje cvs_manual. V repository si CVS systém za jméno souboru ukládá čárku a písmeno v. Takže v repository je tento soubor uložen jako cvs_manual.html,v. Dále pokračuje číslo verze, v našem případě 1.1. Poté následuje datum a čas na nultém poledníku, přihlašovací jméno toho, kdo jej uložil, a stav verze, kde Exp znamená experimentální verzi, Stab stabilní verzi a Rel verzi určenou k distribuci. Tak jsou všechny informace po ruce přímo v souboru. Podíváte-li se do mnohých kódů například pro Linux, mnohdy tam klíčové slovo $Id$ najdete.

Je jasné, že pokud použijete automatické nahrazování klíčových slov v nějakém souboru, či ve všech, je potřeba klíčová slova dávat do poznámek, aby nenarušily funkci souboru. Například v jazyce C můžete napsat /* $Id$ */, apod. Dále je potřeba dávat pozor, aby se v souboru náhodou nevyskytly řetězce, které CVS pozná jako klíčové slovo (pokud to není váš záměr). Například já v tomto manuálu nemůžu rovnou napsat $Id$, protože by po tomto řetězci CVS okamžitě "skočil", a nahradil jej. Musím využít toho, že znak $ se může v HTML zapsat jako &{}#36;, což už CVS nechá na pokoji. Pokud bych chtěl to samé zapsat v jazyce C, aniž by mi to CVS nahradil, musel bych psát třeba char mytxt[] = "\x24Id\x24";, aby mi ho CVS nechal na pokoji. Dlužno ovšem napsat, že takové situace se v praxi vyskytují velice, velice zřídka, takže problémy vám to nejspíše dělat nebude. V krajním případě, pokud nelze jinak, je možné nahrazování klíčových slov zakázat. Jak to lze provést, se dozvíte ještě v této kapitole.

Občas se vám nehodí, aby systém CVS automaticky nahrazoval klíčová slova, a tak máte možnost tento proces řídit. Standardně CVS nahrazuje klíčová slova ve všech souborech v projektu. CVS umožňuje ke každému souboru sdělit, jaký režim nahrazování klíčových slov použijete. Tento režim je možné určit pomocí příkazů add při registraci souboru, a nebo pomocí příkazu admin ho kdykoli později změnit:

  • cvs add -krežim jmeno_souboru
  • item nastaví režim nahrazování klíčových slov při registraci souboru

  • cvs admin -krežim jmeno_souboru
  • item nastaví režim nahrazování klíčových slov kdykoli později

U volby -krežim se mohou použít tyto možnosti:

  • -kkv - standardní nahrazování klíčových slov, ale nepřidává přihlašovací jméno toho, kdo zamkl soubor. Příklad: $Id: cvs_manual.html,v 1.30 1999/12/31 12:58:15 ponkrac Exp $
  • -kkvl - standardní nahrazování klíčových slov, ale navíc přidává přihlašovací jméno toho, kdo zamkl soubor, pokud je zamknutý. Příklad: $Id: cvs_manual.html,v 1.30 1999/12/31 12:58:15 ponkrac Exp sandokan $
  • -kk - tato volba je antinahrazování, a pracuje naopak. Smaže vše co bylo nahrazeno, a nechá jenom prázdná klíčová slova. Pokud třeba v souboru máte $Author: ponkrac $, potom po změně tam zůstane jenom $Author$. Příklad: $Id$
  • -kv - nahrazuje tak, že smaže klíčové slovo, a nahradí ho příslušným údajem. Nutno říci, že toto nahrazení není při změně verze přepsáno, protože pro CVS vlastně zmizí klíčové slovo po prvním nahrazení. Příklad:
    cvs_manual.html,v 1.30 1999/12/31 12:58:15 ponkrac Exp
  • -ko - žádná klíčová slova se nenahrazují
  • -kb - žádná klíčová slova se nenahrazují, a navíc systému CVS říkáme, že se jedná o binární soubor.

Práce ve vícečlenném týmu

Pokud pracujete na projektu, v podstatě to normálně probíhá tak, že provedete v nějakém svém adresáři příkaz checkout, kterým si nahrajete aktuální verzi projektu na svůj disk do nějakého pracovního adresáře. To v podstatě udělají všichni, kteří se na projektu podílejí. Mezitím každý z nich pomocí příkazu commit svojí práci nahrává zpět do systému CVS. Pokud Vás pracuje na projektu více, potřebujete se občas přesvědčit, co se na projektu změnilo, zatímco pracujete. Pokud se chcete pouze přesvědčit, jedno z řešení je použít příkaz status, který porovná soubory ve vašem pracovním adresáři s nejnovější verzí uloženou v systému CVS:

cvs status

Pokud si příkaz vyzkoušíte, program mezi spoustou jiných informací vypíše ke každému souboru File: plus stav vaší pracovní verze. Tento stav je jeden z následujících:

  • Up-to-date - soubor v pracovním adresáři je shodný s nejnovější verzi v CVS.
  • Locally Modified - soubor v pracovním adresáři je novější, než verze v CVS. To značí, že jste na tomto souboru prováděl změny, a bude potřeba je později nahrát do CVS příkazem commit.
  • Needing Patch - soubor v systému CVS je novější, než v pracovním adresáři. Znamená to, že jste na tomto souboru nepracoval, ale mezitím někdo jiný nahrál novější verzi do CVS. Pokud potřebujete nutně tento soubor pro svoji práci na projektu, měl byste si stáhnout novější verzi pomocí příkazu update, a nebo natáhnout vše znovu pomocí checkout.
  • Need Merge - došlo ke konfliktu. Zatímco jste pracoval na souboru, pracoval na něm též někdo jiný, a mezitím nahrál tuto verzi do CVS. Ale i takovéto konflikty umí CVS řešit, bude potřeba změny sloučit pomocí příkazu merge.

Takto to vypadá jednoduše, problémem ale je, že příkaz status je trochu "ukecanější", takže najít tam výše uvedené informace není až tak jednoduché, nebo pohodlné. Téměř ideální řešení nabízí unixová utilita grep, která dokáže vyřešit problém velice elegantně a odfiltrovat nepotřebný text. Ve Windows standardně neexistuje prostředek, který by byl schopen odfiltrovat nežádoucí informace. Doporučuji si proto někde opatřit verzi utility grep pro Windows, pokud používáte tento systém. Bývá buď součástí překladačů firmy Borland, a nebo lze využít GNU verzi, či verzi dodávanou s freewarovým C/C++ překladačem CygWin pro Windows. Pokud se po této utilitě nechcete pídit, napište mi na moji e-mailovou adresu, a já vám tuto utilitku pošlu ve verzi pro Windows.

S utilitou grep dostanete velmi přehledný výpis použitím:

cvs status | grep File

Později popíšu ještě jedno řešení, jak zjistit stav pracovního adresáře, a to ke konci popisu příkazu update. Toto druhé řešení používám já při své práci, a dávám mu přednost před příkazem status.

Napsal jsem tedy, jak zjistit, zda vaše pracovní kopie sedí s tím, co je nahráno v CVS. Pokud zjistíte, že potřebujete dohrát novější verze, slouží k tomu příkaz update:

cvs update jmeno_souboru

Příkaz update dohraje ze systému CVS novější verzi souboru, pokud jí mezitím někdo z pracovního týmu nahrál příkazem commit do systému CVS. Jméno souboru v příkazu update je možné vynechat, pak se nahrají všechny novější verze souborů v systému CVS do vašeho pracovního adresáře.

Tak se nabízí i trochu drsnější postup, a to vykašlat se na zjišťování stavu pomocí příkazu status, a rovnou natvrdo natáhnout změny z CVS do pracovního adresáře. Protože tvůrcům systému CVS bylo jasné, že existují i takové lidské vlastnosti, jako je lenost, podpořili i tento postup. Proto příkaz update garantuje, že nezničí žádnou vaši práci. Jak přesně příkaz update postupuje v jednotlivých případech při možných konfliktech, a jak je řeší, aby neztratil ani ten nejmenší kousek vaší práce na projektu, či práce dalších lidí v týmu, si ukážeme za chvilku.

Pokud použijete příkaz update, systém CVS vypisuje pro každý soubor jednu řádku, a to zhruba tak, že vypíše nějaké písmeno, a pak po mezeře jméno souboru. Vypadá to například takto:

U soubor.txt
? soubor.bak
A readme.txt

Co tedy znamená první písmeno na každém řádku ve výpisu souboru? Tímto nás systém CVS informuje o tom, co vlastně provedl, nebo by se mělo provést. Význam tohoto písmene je možné najít v tomto seznamu:

  • U - byla nahrána novější verze souboru z CVS
  • P - byla nahrána novější verze souboru z CVS, ale systém místo toho, aby přehrál celý soubor použil metodu patche, tedy nahrál jenom rozdíly mezi verzemi. Výsledek je stejný, jako v předchozím případě, ale přeneslo se méně dat po síti.
  • A - nic se nestalo, jenom vás CVS upozorňuje, že jste tento soubor zaregistrovali pomocí příkazu add, a ještě jste neprovedli příkaz commit. Je tedy potřeba později provést commit.
  • R - nic se nestalo, jenom vás CVS upozorňuje, že jste tento soubor odregistrovali pomocí příkazu remove, a ještě jste neprovedli příkaz commit. Je tedy potřeba později provést commit.
  • M - došlo ke konfliktu, zatímco jste pracovali na souboru, pracoval na něm také někdo jiný, a mezitím nahrál tuto verzi do CVS. Systému CVS se podařilo oba soubory spojit dohromady, a to tak, že prostě do verze z CVS přidal řádky, které máte navíc ve vaší verzi. Navíc vaší původní verzi souboru zazálohoval do souboru s názvem .# plus původní jméno souboru plus tečka a číslo verze vašeho souboru. Doporučuje se prohlédnout obě verze, dát soubor do pořádku a nahrát do CVS příkazem commit. Druhá varianta je, že zjistíte, že buď vy, a nebo ten druhý tam psal nesmysly, a jednu verzi prostě smažete a druhou nahrajete pomocí příkazu commit do CVS.
  • C - došlo ke konfliktu, zatímco jste pracoval na souboru, pracoval na něm též někdo jiný, a mezitím nahrál tuto verzi do CVS. Prostě stejná situace jako u M, i soubor je zazálohován stejně, jenom se liší tím, že CVS nedokázal tak jednoduše spojit obě verze do jedné. Tento případ je podrobněji rozepsán v dalším textu.
  • ? - označuje soubor, který máte v pracovním adresáři, ale není zaregistrován v CVS.

Jak je vidět, příkaz update je celkem bezproblémový, pokud se před jménem souboru neobjeví písmeno C, případně M, které značí konflikt. Znamená to prostě, že více lidí mění stejný soubor. V takovém případě příkaz update konfliktní soubor ve vašem pracovním adresáře zazálohuje. Abych byl trochu konkrétnější, předpokládejme, že konfliktní soubor se jmenuje pokus.c. Vy ho ve svém pracovním adresáři máte ve verzi 1.4. Mezitím někdo jiný nahrál do CVS další verzi, kterou CVS automaticky označil jako 1.5. Vy jste použil příkaz update, který zjistil konflikt. Proto vaši verzi 1.4 přejmenuje na .#pokus.c.1.4, a do souboru pokus.c nahraje jakousi sloučenou verzi, která obsahuje jak novou verzi z CVS, tak i změny, které jste udělal na souboru vy. Dále mohou nastat dva případy, a to buď jde o variantu M, nebo C.

V případě varianty M systém CVS prostě přidal do verze s CVS řádky, které jsou navíc ve vaší verzi. A je spokojený. Ale mezi námi, vyznat se v tom je někdy nad lidské síly, protože musíte pátrat, třeba příkazem diff po tom, co kde spojil. Abych řekl pravdu, jde prostě o to, že se musíte do souboru podívat, dát to do pořádku, a případně vaši novou verzi nahrát do CVS příkazem commit. To samé je nutné i v případě varianty C, která je ale trochu přehlednější. Ve variantě C je totiž jasně vyznačeno, jaký je rozdíl mezi oběma verzemi. Je potom na vás, abyste dal soubor do pořádku, a nahrál zpět pomocí příkazu commit do CVS. Pro ilustraci uvádím část souboru pokus.c s vyznačenými rozdíly mezi vaší verzí a verzí uloženou v CVS:

fprintf(stderr, "No code generated.\n");
<<<< pokus.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
=======
exit(!!nerr);
>>>> 1.5

Z výpisu je patrné, kterou část jste měl vy ve své původní verzi pokus.c, a která část je nahraná ve verzi 1.5 ze systému CVS. Vy potom vymažete ty řádky, které tam nepatří, nahrajete do CVS použitím příkazu commit, a je to.

Dlužno ovšem říci, že byste se pokud možno měli vyhnout této konfliktní situaci, kdy dva lidé editují stejný soubor. A nebo ji alespoň eliminovat na minimum.

Slíbil jsem také zhruba uprostřed této kapitoly, že ukáži jiný způsob, jak zjistit stav pracovního adresáře, a nepoužít příkaz status. Princip je velice jednoduchý, program cvs umožňuje přidat prakticky ke každému příkazu volbu -n, která vyzkouší příkaz naslepo. Je to takové divadlo, program cvs se tváří, že běží, vypisuje vše, co má, ale ve skutečnosti CVS nic nemění, žádnou akci se soubory nikde neprovádí. A co takhle si vyzkoušet příkaz update naslepo? To je ono, protože tím nám bude zároveň vypsáno, jaký je stav souborů v pracovním adresáři. Použijeme také volbu -q, která trochu krotí cvs ve výpisech, takže dostaneme skutečně jenom to potřebné:

cvs -n -q update

Aby to nebylo tak jednoduché, jak je vidět ze zápisu, volby -n, a -q se musí psát před příkaz! Tedy v našem případě před slovo update. Příčina je jednoduchá, tyto volby totiž můžete použít pro každý příkaz, a proto se píší před příkaz. A volby, které slouží jenom pro konkrétní příkaz se píší za příkaz.

Číslování verzí, nastavení čísla verze

Pokud jste pokročili až sem, už toho pro vlastní práci znáte poměrně mnoho. Proto se naučíme některá kouzla, která vám umožní nastavit číslo verze.

Pokud se systémem CVS již nějakou dobu děláte, všimli jste si, že CVS automaticky čísluje verze. Začíná na 1.1, po první změně v nějakém souboru označí soubor jako verzi 1.2, po další jako 1.3, atd. CVS prostě pořád zvyšuje poslední číslici ve verzi. CVS také umožňuje nastavit číslo verze. Pokud tedy nastavíte, že soubor má verzi 3.5, potom po změně ji CVS zvýší automaticky na 3.6, po další změně na 3.7, a tak dále. Je také možné nastavit číslo verze třeba na 2.3.0.5, jak je to obvyklé třeba ve Windows. A CVS potom dodržuje stejnou logiku, po každé změně zvýší poslední číslo za poslední tečkou. Všechny ostatní číslice nemění. Takže v tomto případě se dočkáme po změnách verze 2.3.0.6, a tak dále. Pokud chcete změnit i číslice předtím, musíte to udělat ručně.

Číslo verze se dá nastavit pomocí příkazu commit, a to pokud zároveň použijeme volbu -r, za kterou po mezeře přidáme číslo verze. Takže následující příkaz nastaví všechny soubory v projektu na verzi 2.0:

cvs commit -r 2.0

                       větev 1.3.2.2.3 -> +--|1.3.2.2.3.1|--|1.3.2.2.3.2|-- atd.
                                         /
        větev 1.3.2 ->   +--|1.3.2.1|--|1.3.2.2|--|1.3.2.3|--|1.3.2.4|-- atd.
                        /
                       /
 --|1.1|--|1.2|--|1.3|--|1.4|--|1.5|--|1.6|-- atd.   <- zde je hlavní větev
                            \
                             \
            větev 1.4.4 ->    +--|1.4.4.1|--|1.4.4.2|--|1.4.4.3|-- atd. 

Výpis: Větve - práce na několika verzích současně

Po této akci označí všechny soubory v projektu na verzi 2.0, a CVS bude dále zvyšovat při každé změně poslední číslo. Je samozřejmé, že se vám číslování začne trochu "rozcházet", protože v projektu to obvykle vypadá tak, že některé soubory změníte jednou, některé vícekrát. Soubor, který jste změnili jednou pak bude mít verzi 2.1, po další změně 2.2, a tak dále. Ale CVS vám mění pouze poslední číslici, vy víte, že se všechno týká 2. verze.

Je samozřejmě možné nastavit číslo verze jenom u jednoho souboru, a to tak, že jméno souboru uvedete na konci příkazu commit při nastavování čísla verze:

cvs commit -r 3.0 jmeno_souboru

Je jasné, že pokud budete často přečíslovávat verzi, můžete si v projektu vyrobit i velice slušný zmatek. Proto vám CVS nedovolí nastavit všechno, co si namanete. Především vám nedovolí snížit verzi. Pokud se například pokusíte nastavit číslo verze u nějakého souboru například na 1.5, když samotný soubor je v CVS uložen jako verze 1.10, systém CVS vám to nepovolí. Prostě se vám to nepovede. Je tedy jasné, že verze s vyšším číslem je vždy novější. Nemůže to být jinak, protože CVS vám dovolí pouze zvyšovat číslo verze směrem nahoru, ale nikdy ne směrem dolů.

Snad jenom poznámku, tímto způsobem je možné nastavit jenom verzi se dvěma číslicemi, pokud nemáte založenou tzv. větev. Proto zatím používejte jenom čísla verzí se dvěma číslicemi, jako je např. 1.5.

Větve - práce na několika verzích současně

Při práci na projektu se obvykle postupuje tak, že se založí projekt. Tím začne vývoj první verze. Než bude k dispozici funkční projekt v první verzi, tak mezitím pracovníci uloží do CVS řadu meziverzí. Poté je oficiálně ohlášena první verze. Mezitím začne vývoj na další verzi. Dále se může stát, že z první verze vznikne několik větví. Například častým případem je, že z hotové první verze se začne vyvíjet druhá verze, a zároveň se ještě první verze opravuje, aby se vychytaly poslední drobné chyby. Někdy třeba z první verze vznikne několik produktů. Takto vzniká potřeba spravovat více souběžných verzí. Proto nabízí CVS prostředek nazývaný větve (v manuálu CVS nazývaná jako "branch").

Větev představuje jakousi novou odnož projektu. Pro ilustraci jaké verze mohou při použití větve vznikat, uvádím takový malý náčrtek (viz Větve - práce na několika verzích současně).

Na náčrtku je celkem jasné, jak vznikají jednotlivé větve. Prostě si kdykoli řeknete, že začnete novou větev, a můžete na ní pracovat. Kdykoli v budoucnu je potom možné větev ukončit, případně spojit s jinou větví a spojit tak dohromady třeba výsledky práce více týmů. Pro projektové manažery, a pro lepší představu všech bude lepší, když si větve představíte jako jakési subprojekty - dílčí podprojekty většího projektu.

Větev můžeme v základě založit dvěma způsoby, buď tak, že za novou větev prohlásíme přesně to, co teď máme v pracovním adresáři:

cvs tag -b jmeno_vetve

Při tomto způsobu vlastně odstartuje větev, a jako první verze souborů v této větvi budou uloženy verze, které právě máme v pracovním adresáři. Příkaz vyžaduje, abychom větev pojmenovali nějakým jménem.

Druhým způsobem, jak odstartovat novou větev je vytvořit ji jako kopii nějaké verze souborů již uložených v CVS. Tento způsob nevyžaduje, abychom byli v pracovním adresáři projektu, a proto vyžaduje i jméno projektu:

cvs rtag -b -r jmeno_znacky jmeno_vetve jmeno_projektu

Takže, aby to bylo jasné, někde v projektu musíme mít verzi, kterou jsme si označili nějakým jménem. Potom následuje jméno větve, prostě si novu větev nějak pojmenujeme. A nakonec přidáme jméno projektu, ve kterém teď vytváříme novou větev. Nutno říci, že tato druhá verze příkazu už je trochu větší sousto, než první způsob vytváření větve, a asi si na něj troufnete, až budete mít CVS trochu zažité.

Jak jste asi pochopili, každá větev má své jméno. Dokonce i hlavní větev má své jméno, které jste zadali při založení nového projektu příkazem import:

cvs import  jmeno_noveho_projektu jmeno_hlavni_vetve  jmeno_prvni_verze

Podstatné je, že toto jméno větve budete potřebovat při práci. Dá se také říci, že jméno větve je vlastně jméno subprojektu, na kterém pracujete.

Takže dál už je to jednoduché. Pokud chci pracovat na větvi (tedy subprojektu), vytáhnu si pracovní verzi:

cvs checkout -r jmeno_vetve jmeno_projektu

Podobně pracuje i příkaz export.

Pokud jsem v pracovním adresáři, mohu si upgradovat svojí verzi na jinou větev pomocí příkazu:

cvs update -r jmeno_vetve

Pokud provedete příkaz commit, systém CVS automaticky správně rozezná, na které větvi pracujete, a nahraje vaše změny správně, takže stačí obyčejné cvs commit.

Značky - příkaz tag

Teď se trochu rozepíšu o značkách (v originální mluvě manuálů k CVS se nazývají "tagy"). O co jde? Jak vyplývá z předchozího textu, systém CVS si automaticky čísluje verze tím, že zvyšuje automaticky poslední číslici při každé změně. Zároveň vy si můžete u libovolného souboru změnit číslo verze, takže se vám může stát, že nejnovější verze souborů mají nejrůznější čísla verzí. Například projekt může mít pět souborů s tím, že mají následující čísla verzí: 1.1, 2.3, 2.4, 2.5, 3.2. Chcete si pro budoucí účely označkovat právě tuto současnou verzi. Můžete to udělat všelijak, třeba si můžete zapsat datum a čas, a poté si vytáhnout verzi přesně s tímto datem a časem. (Jak vytáhnout starší verzi bude napsáno později.) Jenomže to nepracuje vždy. Ačkoli jsem se o tom zatím podrobněji nerozepisoval, je možné vyvíjet souběžně několik verzí ve stejném čase.

Zkrátka a dobře, nebudu chodit kolem horké kaše, můžete si současnou verzi označkovat, neboli jí nazvat nějakým jménem. K tomu slouží příkaz tag. Například následující příkaz si označkuje pod jménem znacka_1 současnou verzi projektu:

cvs tag znacka_1

Poměrně užitečná je volba -l, která umožňuje označkovat všechny soubory zaregistrované v adresáři, ale nebude označkovávat soubory v podadresářích:

cvs tag -l znacka_1

Nutno ještě podotknout, že volba -l může být použita pro mnoho jiných příkazů, kde má stejnou funkci. Například nechcete-li nahrát do CVS změny celého projektu, ale jenom souborů v aktuálním adresáři, můžete použít:

cvs commit -l

Ještě užitečnější je, že si můžete vybrat, který soubor budete označkovávat:

cvs tag znacka_1 jmeno_souboru

Můžete takto postupně označit několik souborů v projektu.

Takže již víte, že můžete označkovávat verze. Tyto značky se objeví prakticky všude. Pokud si například necháte vypsat logovací výpis pomocí příkazu log, zjistíte, že se v tomto výpisu jména značek objevují. Je jasné, že značky můžete používat jak často chcete, a můžete si vymyslet klidně stovky různých pojmenovaných značek. Jména značek k určitému souboru zjistíte snadno příkazem status:

cvs status -v jmeno_souboru

Tento příkaz vypíše mimo jiných údajů i řádek s názvem Existing Tags:, pod kterým jsou seřazeny všechny značky, které patří k zadanému souboru:

   Existing Tags:
      znacka_1                (revision: 2.0)
      importovana_verze       (revision: 1.1.1.1)
      ponny                   (branch: 1.1.1)

Samotný příklad konce výpisu tedy ukazuje o značkách mnoho. Okomentuji tedy tento výpis. V prvním řádku je psáno, že existuje značka s názvem znacka_1, a že takto byla označkována verze 2.0. Další řádky jsou ale mnohem zajímavější. Abych vám usnadnil pochopení, napíšu, že jsem vypsal soubor z projektu ph, který byl předtím založen pomocí následujícího příkazu import:

cvs import -m "zalozeni projektu" ph ponny importovana_verze

A teď tedy přesně vidíte, co znamenají všechna povinná slova u příkazu import. V podstatě jsem založil projekt s názvem ph, a o založení jsem učinil komentář "zalozeni projektu". Za názvem projektu ph následuje jméno větve ponny. A posledním slovem je název značky, v našem případě má název importovana_verze. Je tedy vidět, že vás CVS již při zakládání projektu donutí vymyslet si jméno značky, které použije pro označkování prvních verzí souborů. To mimo jiné znamená, že můžete kdykoli přesně zjistit, se kterými soubory jste založili projekt.

Poměrně velký počet příkazů programu cvs vám dovoluje použít volbu -r, za kterou po mezeře následuje jméno značky. Tím dostáváte mnoho pomůcek pro práci s projektem. Předem ale musím upozornit, že musíte vědět co děláte. To je potřeba pořádně zdůraznit!

Získání starších verzí souborů z projektu

V některých případech se chcete vrátit ke starší verzi projektu, ať už z jakéhokoli důvodu. A nebo ji prostě chcete mít pro zákazníka, který si nezaplatil nejnovější verzi.

Je například možné vytáhnout soubory z dříve označkované verze:

cvs checkout -r jmeno_znacky jmeno_projektu

Tento příkaz vám vytvoří adresář s názvem ph, a uloží do něj soubory z projektu ph přesně ve verzi, kterou jste si označili značkou se jménem znacka_1. Znovu říkám, buďte opatrní, protože pracujete nejspíše na starší verzi! Používejte toto opatrně, zvláště, chcete-li potom změny nahrávat do CVS příkazem commit! Pokud se vám takto podaří omylem nahrát starší verze souborů, budete muset podniknout určité kroky na uvedení projektu do původního stavu.

Asi častějším případem bude potřeba prostě získat soubory samotné, nikoli v pracovní verzi pro potřeby vývoje, ale prostě jenom samotné soubory. Potom se hodí příkaz export, který se používá stejně jako příkaz checkout, ale na rozdíl od něho příkaz export nevytváří pracovní verzi, ale jenom adresář se všemi soubory patřící do projektu. Například získat nejnovější verze souborů projektu lze takto:

cvs export jmeno_projektu

Automaticky se nabízí, jak vytáhnout označkovanou verzi projektu:

cvs export -r jmeno_znacky jmeno_projektu

Tip: Při založení projektu příkazem import udáváte i jméno značky, které je povinné. Takže možná, aniž jste to tušili, jste si automaticky označkovali verzi souborů při založení projektu. Pokud jste například založili projekt třeba takto:

cvs import -m "zalozeni projektu" prvniprojekt poc-tym poc-verze

Potom jste automaticky označkovali všechny soubory, se kterými jste založili projekt značkou se jménem poc-verze. Potom si kdykoli můžete vytáhnout přesně stejné soubory příkazem:

cvs export -r poc-verze prvniprojekt

Je samozřejmě také možné vytáhnout i verze podle data, třeba takto:

cvs export -D "01/01/2000 00:00" jmeno_projektu

Tento příkaz vytáhne verzi souborů, které byly v CVS 1. ledna 2000 o půlnoci, abyste mohli zákazníkovi dokázat, že tehdejší verze nemohla způsobit problém Y2K. Datum se zadává v pořadí měsíc, den, rok.

Stavy verzí souborů

Při vytváření projektu a práci na projektu se každý soubor dostává v zásadě do tří možných stavů. Je to stav, kdy ho vytváříte, a nemáte ho ještě prozkoušený. Potom nic nezaručujete. Takový stav nazývejme experimentální. Dále je to stav, kdy jste soubor otestovali, můžete říci, že jste se snažili zbavit se všech možných chyb. To je stav stabilní verze. A potom je to stav, kdy soubor prošel testováním, a je určen k distribuci zákazníkovi.

Tyto údaje můžete také systému CVS sdělovat. Pokud mu to nesdělíte, CVS automaticky všechny verze všech souborů bude označovat jako experimentální. Stav souboru v projektu vám vypíše v každém podrobnějším výpise změn, třeba v logovacím výpisu. Taktéž příkaz status vám vypíše stav souboru. Za slovem State: vám vypíše jedno ze tří slov:

  • Exp - experimentální verze
  • Stab - stabilní verze
  • Rel - verze určená k distribuci

Pokud chceme nějakou verzi označit jako stabilní, použijeme příkaz:

cvs admin -sStab jmeno_souboru

Pokud chceme nějakou verzi označit jako určenou k distribuci, použijeme příkaz:

cvs admin -sRel jmeno_souboru

Pokud například označíte soubor pokus.c jako stabilní verzi, nebo určenou k distribuci, platí to pouze pro tuto verzi. Jakmile soubor pokus.c změníte, a natáhnete ho do CVS, potom ho systém CVS automaticky označí zase jako experimentální. Víte tedy, která verze je jaká, a zejména pro vedoucího projektu toto dělení verzí přináší velký užitek.

Základní syntaxe příkazů CVS

Tato kapitola trochu podrobněji podává informace o příkazech cvs. Vzhledem k tomu, že v předcházejícím textu je již mnoho informací o různých volbách, tato kapitola podává celkový pohled na příkazy programu cvs.

Základní syntaxe při používání cvs je:

cvs  globální_volby  jméno_příkazu volby_příkazu  parametry

Ačkoli to vypadá složitě, tak je to jednoduché. Globální volby jsou volby, které můžete (nebo nemusíte) použít pro každý příkaz, a pro každý příkaz znamenají totéž. Potom následuje jméno příkazu, třeba commit. Dále můžete (nebo nemusíte) použít volby, které se vážou jenom k tomu příkazu, který jsme teď použili. Dále mohou následovat parametry, nejčastěji je to jméno souboru nebo projektu.

Protože globální volby jsou stejné pro každý příkaz, vypíšeme si zde ty nejčastěji používané:

  • -d adresář_s_daty_CVS - umožňuje systému CVS říci, kde máte uložená data pro CVS. Pokud jste si nastavili proměnnou CVSROOT, nebudete tuto volbu potřebovat, jinak musíte tuto volbu použít.
  • -e editor - umožňuje říci, že pro napsání komentáře si přejete spustit editor, který se vám líbí. Místo slova editor zadejte cestu k vašemu oblíbenému editoru. Pokud tuto volbu nepoužijete, ve Windows se spustí Notepad. Abyste nemuseli svůj oblíbený editor zadávat při každém příkazu pomocí volby -e, můžete přidat do AUTOEXEC.BAT (ve Windows, Unixáci do .profile) nastavení proměnné CVSEDIT, případně EDITOR.
  • -n - toto je jakési divadlo. Pokud použijete volbu -n, můžete si být jistí, že se nic neprovede, pouze program cvs vypíše na obrazovku to samé, jako by se příkaz provedl.
  • -q - příkaz omezuje množství zpráv na obrazovku. Řekněme, že toho vypíše o trochu méně, a vypisuje jenom podstatnější věci.
  • -Q - dělá z cvs neviditelného nindžu. Prostě se program skutečně krotí, a nevypisuje opravdu nic, pokud nenastanou nějaké vážné chyby. Pokud vše probíhá v pořádku, je program tichý, respektive s čistou obrazovkou.
  • -t - vypisuje naopak co nejvíce na obrazovku. Je vhodné používat společně s volbou -n, pokud chcete vyzkoumat, co určitý příkaz přesně dělá.

Pro odvážné - mazání verzí

Někdy se stává, že vám dochází místo na disku. S každou zaznamenanou změnou vám narůstá velikost prostoru zabraného daty systému CVS. Jak bylo již psáno, každá změna se zaznamenává na věky věků. Pokud jste si jisti, že se již nikdy nebudete potřebovat vrátit k některým verzím, lze je ze systému CVS odmazat, a ušetřit tak něco málo diskového prostoru. Používání této možnosti záleží na vašem stylu práce a také na vašich nervech.

Osobně doporučuji ukládat do CVS verze, které jsou alespoň částečně odladěné. Pokud pracujete v týmu, je nutné, abyste do CVS nahrávali pouze funkční verze, aby vaši spolupracovníci mohli na vašich verzích stavět. Pokud jste ale sám a dáváte přednost tomu, ukládat svoji práci do CVS třeba i vícekrát denně, zejména u krátkodobých projektů, může se vám hodit možnost některé nevýznamné verze později odmazat. Ale pokud chcete znát můj názor, funkce pro odmazávání verzí raději nepoužívám, je možno jimi nadělat velký zmatek.

Pro používání funkce výmazu verzí je potřeba tedy především myslet. Musíte si být absolutně jistí tím, co děláte. Základním příkazem pro odmazání verzí je příkaz:

cvs admin -o číslo_verze jméno_souboru

Pokud chcete odmazat verzi 1.4 souboru budulinek.txt, provedete to takto:

cvs admin -o 1.4 budulinek.txt

Užitečnější je odmazat verze v určitém rozsahu, například od verze 1.3 do verze 2.5. To se provede takto:

cvs admin -o 1.3::2.5 budulinek.txt

Tento příkaz dělá přesně to, že nechá verzi 1.3 a nižší, stejně tak jako verze 2.5 a vyšší, a všechny verze mezi tím odmaže.

Závěr

Systém CVS toho umí mnohem více, než jsem zde popsal. Pokud vás něco o zajímá, můžete mi napsat. Také budu rád za veškeré vaše zkušenosti s CVS. Pokud se k tomu dostanu, rád bych tento manuál ještě rozšířil, takže mi napište i tehdy, pokud chcete mít k dispozici případnou další verzi.

Poděkování

Rád bych zde v této kapitole poděkoval všem, kteří mi pomáhali při opravách tohoto manuálu, a jeho zkvalitňování. Konkrétně bych chtěl poděkovat tomuto člověku: Marianu Foltýnovi za velkou pomoc při odstraňování chyb v tomto manuálu. *


- předchozí článek - následující článek - obsah - úvodní stránka -