![]() ![]() |
ARCHIV |
||||||||||||||||||||||||||||||||||||||||||||||||||
![]() ![]() ![]() ![]() ![]() ![]() |
|
Odezva | Popis |
N | new - přidán nový soubor |
M | modified - změněm soubor |
U | updated - aktualizován soubor |
L, I, C | symbolický odkaz, ignored, conflict - ignorováno |
Ignorovány jsou například soubory s názvem končícím tildou, soubory specifikované v systémové proměnné CVSIGNORE nebo symbolické odkazy.
To je vše, nyní je projekt úspěšně založen. Původní soubory projektu narozdíl od RCS nezmizely. V adresáři $CVSROOT/pro se vytvořily jejich kopie s poznámkami CVS.
Přesuňme se do adresáře, do kterého chceme projekt vyvolat. Mimochodem - toto je příjemná vlastnost. Projekt můžeme vyvolat kdekoliv. To u RCS nešlo. Ve vybraném adresáři spusťme příkaz
$ cvs checkout pro
nebo jeho kratší variantu cvs co. Existuje také příkaz export, který se používá stejně jako checkout s tím rozdílem, že nevytváří pracovní soubory (nevytváří podadresář CVS), ale jen soubory zkopíruje.
V aktuálním adresáři se vytvořil podadresář pro, kde jsou umístěny vyvolané soubory projektu pro. Navíc je tam další adresář CVS.
Možná znáte tuto situaci. Rozhodli jste se k radikální změně v projektu. Přepíšete soubory, změníte strukturu (i když změnu struktury berte s rezervou - pokud nenavrhnete správnou strukturu napoprvé, asi se u CVS objeví problémy...) a ono to stále ne a ne fungovat. Pokud používáte SCM, nemusíte se takových chvil bát. CVS totiž umožňuje vyvolat verzi projektu z libovolného okamžiku. Vyvoláme stav projektu z 6. 6. 2005 22:55, kdy vše ještě fugovalo. K příkazu co nebo up se přidává přepínač -D, který určuje datum a čas. Obvykle se uvádí ve formátu RRRR-MM-DD HH:MM, ale můžeme použít i DD MMM RRRR HH:MM, kde MMM jsou první tři písmena anglického názvu měsíce (Jan, Feb atd.), nebo některou ze speciálních frází. Těmi jsou myšleny řetězce jako "yesterday", "1 hour ago" nebo třeba "last Sunday".
$ cvs co -D"2006-06-06 22:55" pro
Jsme ve stavu, kdy máme projekt vyvolán. To je chvíle, kdy můžeme pracovat na další verzi. Když jsme s úpravami hotovi, budeme chtít projekt zase uložit.
$ cvs commit -m"opraveny chyby"
Je opět možný i kratší zápis - commit lze nahradit za ci.
Problém nastává v případě, kdy se rozroste počet souborů projektu. CVS totiž kontroluje jen změny souborů, zapsaných v projektu. V takovém případě je to nutné dát systému CVS na vědomí.
$ cvs add passwd
Systému CVS jsme právě řekli, aby příště kontroloval i soubor passwd. Jsme v situaci, kdy CVS se souborem passwd počítá, ale přesto zatím není součástí projektu. To musíme udělat opět příkazem cvs commit. Pokud přidáváme soubory v novém podadresáři projektu, musíme stejným způsobem přidat i tento podadresář.
Složitější je to s přidáváním souborů, které nejsou čistým textem - tedy obrázky apod. Je nutné přidat přepínač -k s hodnotou 'b', který specifikuje binární soubor (více o tomto přepínači v části klíčová slova).
$ cvs add -kb foto.png
A co když naopak chceme nějaký soubor odstranit? Mechanizmus je úplně stejný jako u přidávání souborů, jen místo cvs add použijeme cvs remove. Užitečná je volba -f, která soubor odstraněný z projektu smaže i na disku (pokud tam ještě je).
Historii práce na projektu ukáže příkaz
$ cvs history -e
Protože CVS spravuje více souborů, není už práce s historií tak jednoduchá. Svědčí o tom výpis příkazu
$ cvs log
Výstupem totiž je seznam historií jednotlivých souborů projektu (CVS udržuje historii každého souboru zvlášť).
Ve výstupu je u každé verze datum a čas vzniku, autor verze, stav a komentář - tedy stejné informace jako u RCS.
Protože většinou nechceme kompletní informace o projektu, ale jen nějakou jejich část, lze příkaz cvs log všelijak modifikovat. Například pro vytisknutí historie 1 souboru z projektu stačí na konec přidat jméno souboru.
$ cvs log index.c
cvs log s přepínačem -h vypisuje jen hlavičku.
Protože výstup příkazu cvs log je často velmi dlouhý, může se občas hodit přesměrování do souboru.
$ cvs log index.c > ../log/index.c.log
Další užitečné informace o souboru lze získat zadáním příkazu
$ cvs status index.c
Seznam registrovaných souborů projektu získáme příkazem
$ cvs log -R
cvs log dále umí zobrazovat, jak projekt vypadal někdy v minulosti. Změny, provedené do okamžiku 1.1.2005, 12:00 zobrazíme příkazem
$ cvs log -d"2005-01-01 12:00"
Pokud na začátek řetězce, který je hodnotou přepínače -d, připíšeme znaménko <, vypíší se změny od toho okamžiku. Od a do lze kombinovat, navíc lze používat speciální fráze, takže pak vznikají řetězce jako "1 month ago <= 2005-06-29".
Často je nutné přímo v projektu udržovat informace o verzi apod. CVS obsahuje mechanizmus klíčových slov, který takové situaci řeší. Pokud chceme, aby v nějakém souboru bylo vždy datum poslední změny souboru bez ručního zásahu, lze přidat klíčové slovo. Do místa souboru, kde chceme datum stačí umístit řetězec $Date$. Dále se o nic nemusíme starat - stačí uložit projekt a při checkoutu se $Date$ nahradí za $Date:datum a čas vydání verze$ (klíčové slovo $Date$ zůstává, aby CVS poznalo, že zde je tag a příště nahradilo opět aktuálními informacemi).
Mimo $Date$ existují i další klíčová slova.
Klíčové slovo | Popis |
$Author$ | autor |
$Date$ | čas poslední změny souboru |
$Header$, $Id$ | hlavička souboru - cesta, verze, datum, čas, autor, stav; rozdíl - $Header$ vypisuje absolutní cestu, $Id$ jen název souboru |
$Locker$ | jméno toho, kdo má uzamčený soubor |
$Log$ | informace o poslední změně souboru |
$Name$ | jméno tagu |
$RCSfile$ | jméno souboru |
$Revision$ | číslo revize |
$Source$ | absolutní cesta k souboru |
$State$ | stav souboru - Exp, Stab nebo Rel |
V souvislosti s příkazem add jsme se setkali s přepínačem -kb. To mimo jiné znamená, že se nebudou nahrazovat klíčová slova. Existují ještě další podobné přepínače. -kkv a -kkvl znamená, že se klíčová slova budou normálně nahrazovat, -kk nenahrazuje a navíc maže to, co bylo nahrazeno, -kv nahrazuje pouze jednorázově a přepínače -ko a -kb říkají, že se nic nahrazovat nemá.
Změny verze 1.5 oproti 1.4 se vytisknou příkazem
$ cvs diff -r1.4 -r1.5 pro
Tagy jsou symbolická jména pro jednotlivé verze. Občas se hodí jasně označit určité milníky v historii projektu, abychom se k nim mohli snadno vracet.
Obvykle se tagy pojmenovávají velkými písmeny. Vytvoříme tedy tag RELEASE_1 na aktuální verzi.
$ cvs tag RELEASE_1
Kdekoliv, kde bychom psali číslo verze můžeme psát tag. Například pro získání rozdílů mezi verzemi RELEASE_1 a RELEASE_2 nemusíme dávat přepínači -r čísla verzí, ale postačí symbolický zápis.
$ cvs diff -rRELEASE_1 -rRELEASE_2 index.c
Tag můžeme použít i při checkoutu. Verzi RELEASE_1 získáme opět přes přepínač -r.
$ cvs co -rRELEASE_1 pro
Seznam tagů na souboru index.c tiskne příkaz status:
$ cvs status -v index.c
Představme si situaci. Máme projekt ve verzi 1.5 a chceme ho rozdělit do 2 větví. K tomu vytvoříme speciální tag, který označíme přepínačem -b jako větev.
$ cvs tag -b VETEV
Člověk, který bude pracovat na větvi bude volat projekt volat příkazem
$ cvs co -rVETEV pro
Obě větve mohou být nerušeně vyvíjeny vedle sebe.
Příkaz cvs diff v takové situaci samozřejmě porovnává dvě poslední verze aktuální větve.
Dalším krokem je sloučení. CVS ho zvládá s přehledem. Pro samotné spojení verze VETEV s kmenem projektu zadejme příkaz:
$ cvs update -j VETEV
Na konflikty vás CVS upozorní a ty je třeba dodělat ručně. Po spojení větve a kmenu je ještě nutné poslat změny příkazem
$ cvs ci -m"Slouceni vetve VETEV s kmenem"
CVS nám to dovolí pouze v případě, že jsme odstranili konflikty. Proběhl-li příkaz bez chyb, vývoj může směle pokračovat dále ve sloučené verzi.
Ještě si ukážeme, jak CVS zvýrazňuje konflikt. Dojde k němu například v případech, kdy byl modifikován v obou slučovaných verzích stejný řádek. Konflikt začíná řetězcem <<<<<<< soubor a končí >>>>>>> slučovaná_verze. Uvnitř jsou řetězce z obou slučovaných verzí oddělené pomocí =======. U RCS je to podobné - jen verze a název souboru jsou jsou prohozené.
<<<<<<< index.c
retezec_v_prvni_slucovane_verzi
=======
retezec_v_druhe_slucovane_verzi
>>>>>>> 1.26
Vybereme jeden z úseků nebo je vhodně sloučíme. Zbytek smažeme a konflikt je vyřešen.
V této oblasti má CVS velkou mezeru, protože přesun souborů (nemluvě o adresářích) neumožňuje. Používá se několik postupů, jak alespoň nedokonale přesun uskutečnit. Lze hrubě zasáhnout do repozitáře a použít mv (potom to bude vypadat, jako by byl v projektu odjakživa), další možností je soubor nepřesunovat, ale zkopírovat pomocí a pomocí cvs remove starý soubor odebrat. Více se o přesouvání dozvíte např. v manuálu nebo ve speciálním díle seriálu Výlet do říše verzí na root.cz. Ani jedna metoda není dokonalá a vždy mohou nastat problémy.
Příkaz cvs admin umí nebezpečnou věc - měnit historii souborů. Je třeba ho tedy používat opatrně. My si ukážeme jen dvě nejčastější užití, ale v dokumentaci najdeme spoustu dalších možností.
To, že se přepíšeme při komentáři se občas stane téměř každému. Protože jde o důležitou součást informací o verzi, je nutná oprava. Ke změně komentáře slouží přepínač -m.
$ cvs admin -m 1.17.1.2:"novy opraveny komentar" data
Příkaz změnil komentář k verzi 1.17.1.2 souboru data. Všimněme si, co a jak je předáváno volbě -m. Číslo verze je dvojtečkou odděleno od samotného komentáře.
Další častá změna nastává, když zjistíme, že jsme do projektu importovali binární soubor jako textový. Přepínač -k mění systém nahrazování klíčových slov.
$ cvs admin -kb foto.png
Zatím jsme se nezabývali situací, kdy pracují vývojáři současně na projektu a ve stejném okamžiku ho upravují. Podobný problém jsme už řešili - při slučování větví projektu.
Máme dva uživatele - petr a adam. Oba ve stejné chvíli pracují na projektu. adam změnil soubor data a odeslal jej do repozitáře. petr nezávisle na něm změnil soubory data a index.c. Nyní by je chtěl také odeslat.
Předtím se musí petr přesvědčit příkazem cvs status, zda již někdo neupravil některý ze souborů, který změnil. Pozná to podle položky Status: Needs Merge. Pro rychlý přehled je užitečné volat
$ cvs status | grep Status
Zde jsou ty nejčastější statusy:
Status | Popis |
Up-to-date | pracovní soubor je aktuální |
Need Merge | konflikt |
Locally Modified | pracovní soubor je novější než soubor v repozitáři |
Needing Patch | pracovní soubor je naopak starší - někdo ho změnil a měli bychom updatovat projekt |
Locally Added | v pracovní kopii je nový soubor, který ještě není v repozitáři |
Locally Removed | v pracovní kopii je smazán soubor, který ještě v repozitáři je |
petr vidí, že soubor data upravoval současně s ním adam. Proto musí nejprve sloučit svoji a adamovu verzi:
$ cvs update
Konflikty je opět nutné řešit ručním zásahem. Teď už petrovi nic nebrání poslat sloučenou verzi do repozitáře.
Ještě si velmi stručně povíme, jak je to u složitějších projektů. Tam se používají tzv watches (kukátka). Vývojář si nechá hlídat, zda někdo nemění sledovaný soubor. Pokud ano, pošle se mu automaticky email.
Je nutné vytvořit nový administrační soubor $CVSROOT/CVSROOT/users a upravit soubor $CVSROOT/CVSROOT/notify. Obsah adresáře $CVSROOT/CVSROOT je pouze pro čtení. Lze ale, stejně jako u obyčejných projektů, vyvolat jeho pracovní kopii:
$ cvs co CVSROOT
V souboru $CVSROOT/CVSROOT/notify odkomentujeme (případně přidáme) řádek:
ALL mail -s "CVS notification" %s
Je samozřejmě možné použít jakýkoliv jiný příkaz než mail nebo si ten stávající upravit k obrazu svému.
Vytvoříme soubor users. Bude obsahovat řádky ve formátu uživatel:hodnota. Právě zde uvedenou hodnotou se nahradí %s z minulé ukázky kódu. V našem případě bude hodnotou emailová adresa. Sem se budou posílat upozornění. Tedy konkrétně například:
petr:petr@neco.cz
A nakonec projekt CVSROOT commitneme.
$ cvs add users
$ cvs ci
Necháme si jako uživatel petr hlídat soubor index.c.
$ cvs watch add -aall index.c
To je vše. Teď se přihlásí adam. Vyvolá projekt a příkazem cvs edit index.c dá najevo, že bude soubor index.c upravovat. Jakmile zadá cvs edit, pošle se email uživateli petr, který si nechal tento soubor hlídat.
Co si pod tím vlastně představit? Jednoduše to, že repozitář (server) bude na speciálním počítači. Na jiných počítačích budou klienti a ti mohou stahovat z repozitáře data.
Vytvoříme si takový server. Do /etc/services přidejme řádek:
cvspserver 2401/tcp
Dále vytvořme soubor /etc/xinetd.d/cvspserver s tímto obsahem:
service cvspserver
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/cvs
server_args = -f --allow-root=/cesta/k/repozitari pserver
}
Teď restartujeme xinetd:
# /etc/init.d/xinetd restart
Nakonec ještě vytvoříme soubor $CVSROOT/CVSROOT/passwd, do kterého přidáme řádky ve tvaru
cvs_login:passwd_des:systemovy_login
Takto vytvoříme uživatele user bez hesla se systémovým loginem petr:
user::petr
Server je připraven, teď zbývá nakonfigurovat klienta. Jako $CVSROOT nastavíme
:pserver:uzivatel@adresa_pocitace:/cesta/k/repozitari
Tedy konkrétně například
$ export CVSROOT=:pserver:user@192.168.0.1:/home/cvsroot
Zalogujeme se příkazem cvs login:
$ cvs login
Logging in to :pserver:user@192.168.0.1:2401/home/cvsroot
CVS password:
$
A to je vše! Teď můžeme vesele pracovat se vzdáleným repozitářem.
Nicméně v této souvislosti zmíňme ještě jeden globální parametr, a to -z. Jako hodnotu mu přiřaďme číslo 1 - 9, které specifikuje úroveň komprese (1 - nejmenší, 9 - největší). Takže budeme vzdáleně checkoutovat například takto:
$ cvs -z5 co pro
Pro ty, kteří používají KDE je dobrou volbou Cervisia. Umí spolupracovat s Quantou a Konquerorem. Volbou Repository->Získat checkoutujeme projekt a následně zobrazíme jeho pracovní kopii pomocí Soubor->Otevřít repository. Ovládání je více méně intuitivní.
Dalším GUI klientem je TkCVS.
Vynikající utilitou je také CvsGraph. Z CVS a RCS repozit souborů umí generovat grafické stromy. Příkazem
$ cvsgraph -r/cesta/k/repozitáři -ostrom.png soubor,v
se zapíše grafický strom souboru soubor,v do strom.png. Může vypadat přibližně takto:
CVS není zdaleka dokonalé (o čemž hovoří např. článek Stinné stránky CVS na root.cz) a postupem času to lidem začalo docházet. Vzniklo tak mnoho projektů, které měly za cíl CVS nahradit. Asi nejvíce se cíli přiblížil Subversion.
Cílem Subversion je podobné ovládání jako CVS a zároveň odstranění jeho nedostatků. Podporuje už i přesouvání souborů a mazání adresářů. Více se o Subversion nebudu rozepisovat, protože se chystá zvláštní článek.
Dalším velmi známým správcem verzí je BitKeeper. Problémem je, že má komerční licenci a uzavřený zdrojový kód. O jeho mimořádných kvalitách svědčí i to, že do letoška byl využíván i při vývoji linuxového jádra.
Jinými známými SCM jsou GNU Arch a Monotone.
Příspívat do diskuze mohou pouze registrovaní uživatelé. |
28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1
12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář
6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář
4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář
18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář
9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business.
Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář
12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář
16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář
31.7.2023 14:13 /
Linda Graham
iPhone Services
30.11.2022 9:32 /
Kyle McDermott
Hosting download unavailable
13.12.2018 10:57 /
Jan Mareš
Re: zavináč
2.12.2018 23:56 /
František Kučera
Sraz
5.10.2018 17:12 /
Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?