Přesouvání souborů
V některém z minulých článků jsme se seznámili s mnoha nedostatky CVS, jedním z nejvýznamnějších je bezesporu nemožnost rozumným způsobem přejmenovat či přesunout soubor (přejmenování souboru je vlastně jeho přesunem v rámci jednoho adresáře, takže je zbytečné neustále vypisovat obě slovesa).
Máme k dispozici několik možných variant řešení tohoto problému. Bezesporu nejjednoduší (a občas bohužel jedinou možnou) variantou je prostě starý soubor smazat a přidat nový. To lze bez problémů vykonat standardními cestami, nepotřebujeme přímý přístup do repository a vůbec s tím nemáme moc starostí. Tedy ve chvíli, kdy tuto akci provádíme; z dlouhodobého hlediska to je horší. Zásadní problém totiž je, že přijdeme o veškerou historii a s tím spojené informace o souboru – nefunguje pořádně cvs annotate ani cvs diff (zajímá mne, co se změnilo ve zdrojáku mezi 20.1. a 27.1., i přes to, že ho nějaký chytrák mezitím přejmenoval z util.c nautils.c) a výstupy z cvs log musíme různě kombinovat.
Nuže, druhá možnost je tvrdý ruční zásah do repository příkazem mv, tedy mv util.c,v utils.c,v a máme po starostech. Zdánlivě. Soubor sice nyní máme pod novým jménem a zachovali jsme jeho historii, ovšem zato jsme zásadně narušili dějinné kontinuum celého modulu. Stačí se totiž třeba vrátit v čase před okamžik přejmenování souboru a máme vážný problém, soubor se totiž tváří, jakoby žil pod svým novým jménem i před dvěma lety, kdy jsme ho do modulu přidali. Pokud jsme takovýmto způsobem třikrát v historii projektu přeorganizovali celý modul, cesty do minulosti (mohou být velmi užitečné, podle Murphyho zákonů (které fungují) zejména tehdy, pokud jste s nimi původně nepočítali a dělali podobná zvěrstva) se stanou téměr nemožnými a raději tiše trpíte. A to ani nemluvím o obdobných problémech v modulu s vícero větvemi…
Co nám tedy zbývá? Inu, teď jsme soubor v repository přesouvali, co takhle ho raději zkopírovat? Oproti předchozí metodě odpadne většina nevýhod – stále bude možné cestovat v historii a používat paralelně několik větví. Sice v nich budeme mít dvě kopie daného souboru místo jedné, ovšem to je myslím mnohem lepší než nemít onen soubor vůbec ;-). Po zkopírování v repository a update vycheckoutovaného stromu stačí pomocí cvs remove odstranit původní soubor a obě instance souboru commitnout s lokálním parametrem -f a nějakou deskriptivní hláškou (-m"util.c → utils.c"). Díky parametru -f budeme mít i v historii nové instance souboru záznam o přesunu souboru i o jeho původním jménu.
Prakticky ve všech případech je tedy zřejmě lepší soubor zkopírovat, snad pouze kromě situace, kdy je hodně velký, dvě kopie by zabíraly neúnosně mnoho místa a příliš by zpomalovaly; pak stojí za to porovnávat plusy a mínusy. Další výjimkou může být kompletní reorganizace modulu, musíme zvážit, jestli chceme raději bezproblémovou funkci několika větví paralelně a cesty do minulosti, nebo se zbavit původní naprosto zbabrané adresářové hierarchie.
Adresář sem, adresář tam
Pokud provádíme nějakou rozsáhlejší reorganizaci projektu nebo jednoduše rušíme určitý adresář, opět máme na výběr. Korektní variantou je jednoduše smazat veškeré soubory v něm obsažené a striktně používat update s parametrem -P, díky kterému budou ignorovány všechny prázdné adresáře. Přitom v ostatních větvích, které případně onen adresář využívají, vše bude fungovat tak, jak má, stejně jako v našich výletech do minulosti.
Nebo také můžeme natvrdo adresář z repository smazat, pokud jsme jednoduše jeho obsah přesunuli někam jinam a jsme si jistí, že ho již opravdu nikdy nebudeme potřebovat. Krom toho, že potřebujeme přímý přístup k repository, si samozřejmě tato metoda nese řadu dalších nevýhod, obdobných problémům s ručním přesouváním souborů. Nebudou nám fungovat ani paralelní větve, ani cesty do minulosti.
Přesto se však k této metodě občas můžeme uchýlit. Takové adresáře se můžou časem dosti nepříjemně nahromadit, a přitom každý cvs updateje všechny prochází, jestli se v nich náhodou neobjevilo něco nového; za chvíli to začne z mnoha důvodů jít na nervy, to mi věřte.
A pak občas začneme zkoušet něco podivného, například si usmyslíme, že přesuneme build system (configure.in a takové ty věci okolo) z kořenového adresáře modulu do podadresáře build/, aby nám nezavazely. Tak se do toho tedy pustíme, všechno si hezky průběžně commitujeme do CVS, až se zasekneme a zjistíme, že dokud používáme automake, tak prostě něco takového udělat nejde a naše úmysly jsou zmařeny. Nezbývá tedy než obnovit vše do původního stavu; Pak samozřejmě nemá smysl adresář build/, který byl stejně pouze několikahodinovým experimentem, v modulu udržovat.
Administrace CVS pro každého
Často se stane, že potřebujeme udělat v repository nějakou administrativní úpravu, od opravy překlepu v log message nějaké revize až po úpravu různých parametrů RCS souboru, které se v CVS obvykle příliš nevyužívají (ovšem poctiví čtenáři je jistě znají ze začátků našeho seriálu, ať již se jedná o popis souboru, či třeba stav revize).
Pro tyto případy nám nabízí CVS poměrně mocný příkaz cvs admin. Ten může využívat každý, kdo má možnost zápisu do repository, může se z něj však stát nebezpečná zbraň, neboť může doslova měnit historii, jak si ukážeme. Doporučuji mu při psaní věnovat podobnou pozornost jako třeba příkazu rm, poněvadž umí často pracovat nad několika soubory najednou a některé operace klidně udělá nad celým adresářem (včetně podadresářů), pokud mu žádné konkrétní soubory nespecifikujeme.
Narozdíl od většiny ostatních příkazů CVS je tento mnohoúčelový a jednotlivými parametry mu musíme upřesnit, co od něj vlastně chceme. My si zde kvůli zachování rozumného rozsahu článku projdeme pouze ty nejužitečnější a nejzajímavější parametry, ovšem ti zvídavější si jistě pozorně pročtou kompletní dokumentaci – vězte, že cvs admin skrývá opravdu širokou paletu nástrojů!
- Úpravy log messages
- Občas se při commitu uklepneme, a buď se nám do log message dostane překlep, objeví se v ní nějaká faktická chyba, nebo ji dokonce omylem necháme prázdnou. A tak nám přichází na pomoc cvs admin -m, který nás hrdinně zachrání od všeho zlého. Jako další parametr si bere číslo revize a novou log message, oddělené dvojtečkou: cvs admin -m 1.2:„Opravená log message.“ util.c. Tento příkaz naštěstí patří mezi ty, které odmítnou pracovat nad více než jedním souborem, poněvadž i když jsme commitnuli několik souborů najednou, zřejmě má každý jiné číslo revize, proto musíme příkaz pustit pro každý soubor zvlášť (číslo revize vytvořené naším commitem se v jeho průběhu dozvíme z kryptických hlášek, které pronáší).
- Keyword substitution
- Někdy se hodí mít možnost upravit režim nahrazování klíčových slov. A proto je tu také cvs admin -k! Například pokud jsme zapomněli při commitu uvést, že je soubor binární, můžeme to napravit: cvs admin -kb Zadani.doc. Ovšem pozor, tento příkaz pro změnu pracuje klidně nad celým repository, pokud mu nezadáme konkrétní seznam souborů a takové zaběhlé -kv může být devastující.
- Stav revize
- Pokud se vám v RCS zalíbila možnost určit u každé revize její status (Exp, Stab, Rel), pak vás jistě potěším příkazem cvs admin -s. Jako parametr si bere status, který má nastavit, případně ještě číslo revize, oddělené dvojtečkou: cvs admin -s Stab:1.9 crash.c. Pokud číslo revize vynecháme, vezme se poslední revize souboru – v takovém případě se tento příkaz nechá použít i na vícero souborů najednou.
- Popis souboru
- Když už jsme u toho RCS, CVS nám dává i možnost nastavit popis souboru, jak jsme si ho vymýšleli při vytváření RCS souboru. Pokud vám schází, využijte cvs admin -t. Za něj buď přilepíme jméno souboru, ze kterého se má popis natáhnout (cvs admin -tpopis crash.c), přímo popis souboru, oddělený pomlčkou (cvs admin -t-„Na nezbedné uživatele…“ crash.c), nebo napíšeme jenom samotný parametr -t; v tom případě se popis natáhne ze standardního vstupu.
- Nastavení výchozí větve
- Při normálním checkoutu se k nám obvykle dostane HEAD, tedy „základní“ kmenová větev. Ovšem někdy bychom raději, aby byla výchozí nějaká jiná větev. Jednoduché, jasné, prosté: cvs admin -bVETEV. Pokud za -b nepřidáme další parametr, nastaví se jako výchozí větev opět HEAD.
- Mazání revizí
- Správně, pokud chcete, můžete jedním příkazem anihilovat třeba celou historii souboru. cvs admin -o se vám o to postará, musíte mu však ještě povědět revize, které chcete smazat. Buď číslo konkrétní revize, nebo rozsah revizí – krajní revize, oddělené jednou (revize se berou včetně) či dvěma (krajní revize se nemažou) dvojtečkami. Pokud jednu z okrajových revizí vynecháme, bere se místo ní první resp. poslední revize. Takže například cvs admin -o 1.6:: crash.c smaže všechny revize od 1.7 výše. Tento příkaz ale raději nepoužívejte ;-).
Příště se budeme intenzivně zaobírat druhou stránkou administrace, tedy konfiguračními soubory v modulu CVSROOT.
