Hlavní navigace

Výlet do říše verzí: RCS

10. 3. 2003
Doba čtení: 7 minut

Sdílet

Naše výprava královstvím RCS pokračuje! Dnes se dozvíte něco více o zamykání souborů, spoustu si toho povíme o větvení vývoje a nakonec si ukážeme, co a k čemu jsou stavy revizí.

Zamykáme, odemykáme, páčíme

O používání RCS ve více lidech se toho ode mne moc nedozvíte; osobně jsem nikdy neviděl nikoho něco takového s RCS provádět a sám s tím nemám žádné zkušenosti. Z mých teoretických znalostí zároveň vyplývá, že je nakonec moudřejší v takovém případě použít pokud možno přeci jen CVS nebo přinejhorším společný účet a screen -x ;-). Praktická užitnost této podpory v RCS je tedy natolik malá, že bude zřejmě lepší věnovat místo hezčím a užitečnějším záležitostem.

Přesto se však musíme zmínit o jedné záležitosti, která s podporou více uživatelů souvisí, a to zamykání. Jak již víme, jedná se o (dosti neohrabaný) způsob, jak koordinovat současnou práci více lidí na souboru a zajistit, aby si jejich změny vzájemě nepřekážely. Proto soubor může modifikovat (resp. registrovat změny v něm) jenom ten, kdo ho má právě zamčený.

Zámek si k souboru pořídíme už při jeho checkoutu, případně checkinu, pokud přidáme parametr -l. Napadlo-li nás soubor měnit až později, použijeme příkaz rcs -l soubor; pokud si to zase rozmyslíme, můžeme soubor odemknout příkazem rcs -u soubor.

Pokud vždy pracujeme pouze s jedinou vycheckoutovanou kopií souboru (což je asi zdaleka nejobvyklejší situace), zamykání a odemykání je prakticky zbytečné, ba naopak nám často práci velmi ztěžuje (například při checkoutování různých revizí souboru za sebou, pak musíme dávat pozor, abychom náhodou zámků najednou neměli několik). Proto bývá často praktické u souboru zamykání co nejdříve zrušit, a to příkazem rcs -U soubor — od této chvíle nemusíme soubor zamykat ani odmykat, registrovat změny můžeme, kdy chceme, apod. Pokud bychom opět chtěli nastolit přísnější režim, obnovíme nutnost zamykání souborů pomocírcs -L soubor; od této chvíle však budu předpokládat, že máte zamykání vypnuté, jinak by z toho v příští kapitolce brzy rozbolela hlava mě i vás. Připomenu, že aby nám při registraci změn nezmizel původní soubor, ale nevytvářely se zároveň různé zámky, které tu už nemají co dělat, použijeme u příkazu ci parametr -u (místo -l). U příkazu co parametr -u jednoduše vynecháme.

O vývoji větveném

Minule jsme si jako pokusného králíčka vytvořili soubor, který obsahoval několik různých pozdravů, a nyní se ho tedy rozhodneme v určité verzi uvolnit pro veřejnost, pokud by se hodil ještě někomu jinému (například do ČNK ;-). Do souboru budeme chtít přidávat další pozdravy, ovšem verzi pro veřejnost budeme chtít udržovat stabilní a její obsah původní — na druhou stranu by nebylo na škodu mít možnost opravovat i v této verzi případné chyby (a mít o tom příslušné historické záznamy).

Nadešel tedy čas rozvětvit vývoj (tomu se často říká fork) — na jednu stranu se bude ubírat naše soukromá nejaktuálnější větev, kdežto v určité revizi nám z ní vyraší větvička (branch) veřejná, kam budou v dalších revizích přibývat pouze opravy různých chyb. Jak to ale zařídit v praxi? Jedno zřejmé řešení je jednoduše soubor zkopírovat, ovšem tím přijdeme o všechnu jeho historii; pokud zkopírujeme i ,v soubor, stále nebudeme mít veškerý vývoj týkající se našeho králíčka na jednom místě, ale roztroušený v n souborech, kde budeme muset dohledávat různé změny; krom toho zabere duplikátní historie zbytečně nějaké místo a ztíží se nám trochu proces slučování (merge) změn v různých větvích.

Proto nám RCS přináší samo určité prostředky, jak udržovat několik větví jednoho souboru pouze v jediné jeho instanci — místo standardní větve (head) můžeme z jakékoliv revize (i když pravda obvykle z té aktuální) oddělit i větve jiné a pracovat v nich nerušeně dále — cokoliv zaregistrujeme, se týká jenom naší aktuální větve (té, kterou máme vycheckoutovanou). Aby se nám s větvemi dobře pracovalo, bylo by vhodné si je očíslovat podobně jako revize — a protože je pro větev zásadní, z které původní revize vychází, vezmeme si za základ právě toto číslo. Větví však může z jedné revize vycházet více, přihodíme tedy nějaké přirozené číslo, rozlišující takové větve. Čísla verzí v každé větvi pak budou mít za základ číslo větve a číslo revize. Pokud tedy v revizi 1.2 našeho souboru ahoj vytvoříme novou větev, její číslo bude 1.2.1; první revize v této větvi bude 1.2.1.1, pokračovat budeme 1.2.1.2 etc. Samozřejmě že můžeme větve samotné libovolně dále větvit, pokud tedy ve verzi 1.2.1.4 získáme potřebu odvodit z ní další dvě větve (brněnské nářečí a verze bez diakritiky), čísla takových větví budou 1.2.1.4.1 a 1.2.1.4.2.

Z takových dlouhých řetězů čísel začíná jít trochu strach, pojďme si tedy raději ukázat, jak to bude fungovat v praxi. Obvykle nás ci nenechá zaregistrovat novou verzi, pokud neobsahuje žádné změny, pomůžeme mu tedy parametrem -f (f jako force) (nic nám nebrání dělat v souboru změny přímo při větvení, parametr -f potom můžeme samozřejmě vynechat):

pasky@machine:~/rcstest$ ci -f -u1.2.1 ahoj
ahoj,v  <--  ahoj
new revision: 1.2.1.1; previous revision: 1.2
enter log message, terminated with single '.' or end of file:
>> Veřejná větev.
>> .
done

Voil`a! Stačilo zadat jako číslo revize číslo větve, kterou chceme vytvořit, a ci udělalo zbytek práce za nás. Dokonce si domyslelo z čísla větve i nejnižší volné číslo revize v této větvi (při druhém použití stejných parametrů by číslo nové revize bylo 1.2.1.2). Tak to funguje nejenom pro ci, ale vždy (nebo téměř vždy), když někam píšeme nějaké číslo revize. Pozn.: nemusíme nutně vytvářet větev vycházející z aktuální revize souboru; ovšem v opačném případě budou do první revize nové větve samozřejmě zahrnuty všechny změny mezi „větvící“ a aktuální revizí, což obvykle není zrovna to, co bychom si přáli.

Nyní se zároveň vývoj automaticky přesunul do nově vytvořené větve, protože aktuální revize souboru je teď 1.2.1.1. Současná větev je tedy 1.2.1, a pokud zaregistrujeme nějakou změnu, projeví se to pouze v této větvi:

pasky@machine:~/rcstest$ echo \# Veřejná verze >>ahoj
pasky@machine:~/rcstest$ ci -m"Přidán koment o veřejné verzi." ahoj
ahoj,v  <--  ahoj
new revision: 1.2.1.2; previous revision: 1.2.1.1
done

Výborně, zapomněli jsme na parametr -u a soubor ahoj nám zmizel, rovnou si tedy ukážeme, jak získat určitou revizi (nebo poslední revizi určité větve) souboru:

pasky@machine:~/rcstest$ co -r1.2.1 ahoj
ahoj,v  -->  ahoj
revision 1.2.1.2
done

Úplně stejným způsobem můžeme přebíhat z jedné revize na druhou, i když soubor máme už vycheckoutovaný. V tom případě se nás co pro jistotu zeptá, jestli může starou vycheckoutovanou verzi smazat (a nahradit ji verzí, kterou po něm chceme teď):

pasky@machine:~/rcstest$ co -r1 ahoj
ahoj,v  -->  ahoj
revision 1.2
writable ahoj exists; remove it? [ny](n): y
done

Revize stavu stabilně nestabilního

Nepříliš známým mechanismem RCS je možnost nastavit různým revizím určitý stav, ve kterém se nacházejí. Ve výstupu příkazu rlog (a na některých jiných místech, o kterých si budeme vyprávět v příštím dílu) se u každé revize zobrazuje i přihrádka „state:“, která má obvykle hodnotu Exp, a právě s tou si budeme hrát.

Stav revize může být buď Exp (Experimental, defaultní hodnota),

Stab (Stable, soubor by měl být již v rozumném stavu), nebo Rel (Released, tuto revizi jsme uvolnili pro veřejné použití). Co když tedy tuto hodnotu chceme změnit? Základní postup jest u příkazu ci při registraci přidat parametr -s, za který napíšeme nový stav (tedy třeba ci -sStab). Ovšem ani pokud již je revize dávno zaregistrovaná, nejsme ztraceni — příkazu rcs můžeme předat parametr -s taktéž a kupodivu se používá stejně; ovšem mění stav aktuální revize; pokud se nám to nelíbí, můžeme za název stavu dopsat dvojtečku a číslo revize, u které stav chceme změnit. Tedy pokud jsme se rozhodli, že revize 1.2.1.2 souboru

root_podpora

ahoj je nejzralejší k release, dáme o tom RCS vědět pomocí rcs -sRel:1.2.1.2 ahoj.

Pokud udržujeme stavy revizí na smysluplných hodnotách, je nám okamžitě u každé revize jasné, zda je použitelná, případně zda jsme ji uvolnili pro veřejnost a může ji tedy vlastnit ještě někdo kromě nás. Navíc si můžeme nechat vycheckoutovat poslední revizi v dané větvi, která má nastavený určitý stav — tedy můžeme si jednoduše říci o poslední stabilní nebo vydanou revizi. Ano, opět použijeme náš starý známý parametr -s, například ve stylu co -r1.2.1 -sRel ahoj.

Bohužel se nám sem už nevejde nic rozumného o slučování změn mezi revizemi i celými větvemi (chtěl bych to celé probrat najednou a přeci jen to celé je delší, než jsem očekával), o tom si tedy určitě přečtete příště. Navíc se snad konečně dozvíte něco o některých kouzelných slovech, která mohou RCS naučit mluvit.

Byl pro vás článek přínosný?