Moje odkazy

• Nabídka služeb
• Relational pipes
• SQL-Výuka.cz
• SQL-DK
• Nekuřák.cz
• i1984.cz
• Telekomunikační slovník

Ostatní odkazy

• GNU.org
• FSF.org
• Monča.cz

Obsah článku:

• Trocha historie
• Co jsou verzovací systémy a k čemu jsou dobré
• Proč distribuované verzovací systémy
• Více scénářů práce
• Dnes používané DVCS
• Jak si vybrat verzovací systém
• Závěr

Verzovací systémy jsou jedním z nejdůležitějších vývojářských nástrojů a užitečné mohou být i jinde. V současné době jsou v módě distribuované verzovací systémy – dnes se na ně tedy podíváme teoreticky a v dalších dílech se budeme věnovat prakticky jednotlivým implementacím.

Trocha historie

Systémy pro správu verzí (VCS) nejsou v oboru softwarového inženýrství žádnou novinkou. Už na přelomu 70. a 80. let se používalo SCCS pocházející z Bellových laboratoří, na které navázalo GNU RCS, jehož autorem je Walter F. Tichy z Purdue University. Později si vývojáři oblíbili CVS, jehož historie sahá do června 1986, kdy Dick Grune poslal do diskusní skupiny comp.sources.unix sadu shellových skriptů. Ačkoliv CVS v aktuální verzi tyto zdrojové kódy neobsahuje, používá z nich některé algoritmy. V roce 1989 Brian Berliner navrhl a napsal systém CVS a později se k němu připojil Jeff Polk.

Začátkem 21. století se rozšířil zejména systém Subversion (SVN). Počátky jeho historie sahají do roku 2000, kdy firma CollabNet začala shánět vývojáře pro komponentu svého produktu CEE týkající se správy verzí. CollabNet Enterprise Edition (CEE) dříve využíval systém CVS. Ten se firma rozhodla nahradit, a vyvinula tak zcela nový program – Subversion. Kontaktovali CVS konsultanta a autora knihy Open Source Development with CVS Karla Fogela a jeho kamaráda Jim Blandyho, kteří souhlasili se spoluprací na projektu. Dále se zapojili Ben Collins-Sussman, Brian Behlendorf, Jason Robbins a Greg Stein. V květnu roku 2000 začala detailní analýza a po čtrnácti měsících implementace (31. srpna 2001) se stal Subversion použitelným a vývojáři mu svěřili správu zdrojových kódů samotného Subversionu místo CVS. Což můžeme považovat za důkaz dospělosti systému, podobně jako u kompilátorů, které jsou kompilovány sami sebou.

Zatímco se Subversion šíří do praxe a nahrazuje v té době už mírně zastaralé CVS, začíná se pracovat na nových verzovacích systémech s jinou architekturou. Jsou to decentralizované verzovací systémy jako GNU arch (2001), Darcs (2002) a Monotone (2003). V roce 2005 se objevuje Git, Mercurial a Bazaar. A o rok později pak Fossil – ten sice nepatří k nejpoužívanějším, ale možná nás zaujme integrovanou wiki a systémem na správu požadavků/chyb.

Někteří autoři jako Joel Spolsky dokonce považují distribuované verzovací systémy za nějvětší pokrok v technologiích pro vývoj softwaru. Ať už jim dáme za pravdu nebo ne, jedno je jisté – každá další generace verzovacích systémů přináší zajímavé myšlenky, posouvá hranice výkonu, kapacit a úspornosti, nebo přichází s novou koncepcí. Je poučné sledovat historii a zábavné těšit se na budoucnost. Co nás asi čeká během příštích pár let? Můj osobní tip je jednak čím dál tím větší integrace s dalšími vývojářskými nástroji (správa chyb, testování, projektové řízení…) a jednak větší uplatnění verzovacích systémů i mimo oblast softwarového inženýrství.

Co jsou verzovací systémy a k čemu jsou dobré

Verzovací systém je v dnešní době nepostradatelným pomocníkem snad pro každého vývojáře. Slouží jako úložiště zdrojových kódů a dalších důležitých souborů, uchovává jejich historii (verze) a umožňuje spolupráci s ostatními vývojáři. Uveďme si alespoň pro pořádek, jaké jsou hlavní výhody používání takového systému:

• Uchování historie verzí – Ještě včera váš program fungoval a dneska pořád padá? Honem ve stresu hledáte nějaké zálohy nebo nasazené kopie programu, abyste mohli zákazníkovi dodat alespoň poslední funkční verzi? S verzovacím systémem se vám tohle nestane – jednoduše se vrátíte k verzi, která ještě fungovala (nebo prošla testy) a postupně budete procházet změny a hledat, při které chyba vznikla. Ruční verzování (např. kopírováním do očíslovaných adresářů nebo tarů) je skutečně přežitek a verzovací systém oceníte i u těch nejmenších projektů.
• Týmová spolupráce – verzovací systém je skvělý způsob jak sdílet zdrojové kódy (resp. obecně soubory – třeba týmovou seminárku do školy) s ostatními kolegy. Odpadnou vám starosti se vzájemným přepisováním si souborů na sdíleném disku, nebo věčném otravném kopírování souborů z poštovního klienta na disk a opětové vkládání do e-mailů.
• Práce ve více větvích – zejména při vývoji softwaru se vám bude hodit udržovat více větví téhož programu. Staré verze aplikace mnohdy nemůžete zavrhnout a nepodporovat – je třeba k nim vydávat různé opravy – takže zatímco ve větvi 2.0 budete pracovat na nové a úžasné (byť ještě ne zcela stabilní) verzi svého programu do původní, v produkci nasazené, větvě 1.0 budete dopisovat drobné úpravy a opravy. Také můžete portovat nějakou funkcionalitu z nové větve do staré (sloučit některé změny).

Následující obrázek znázorňuje typické uspořádání – máme společný server, na který jednotliví členové týmu odesílají svoje upravené soubory a stahují si změny, které provedli jejich kolegové. Server je jen jeden a pracovní kopii má každý člen týmu vlastní:

Při postoupení (commit) sady změn (changeset) do společného úložiště vzniká verze – je dobrým zvykem ke každé verzi napsat výstižný textový popis, aby ostatní věděli, v čem změna spočívá, aniž by museli procházet jednotlivé zdrojové kódy.

Proč distribuované verzovací systémy

U centralizovaných systémů máme kompletní historii změn jen na serveru zatímco na klientech bývá jen poslední verze a rozpracované soubory. Také zde máme jasně rozdělené role – server (společné centrum) a klienti (na počítačích jednotlivých vývojářů).

V případě distribuovaných (decentralizovaných) systémů jsou všechny uzly rovnocenné – na všech máme kompletní historii a můžeme se vrátit k libovolné verzi, aniž bychom se museli dotazovat nějakého serveru. Role nejsou pevně dané, můžou se dynamicky měnit – každá kopie (klon) může být v roli „klienta“ i „serveru“.

Z těchto vlastností vyplývají výhody distribuovaných verzovacích systémů:

• Práce offline – s distribuovaným systémem nic nebrání vývojáři aby pracoval třeba v letadle nebo ve vlaku i bez internetového připojení. Může vytvářet nové verze nebo se vracet k těm starým, nepotřebuje k tomu spojení se serverem. Toto velká je výhoda nejen v případě zcela chybějícího, ale i v případě pomalého nebo nespolehlivého připojení (např. mobilního).
• Bezpracné zálohování – Na počítači každého vývojáře máme plnohodnotné úložiště včetně všech historických verzí a větví. Takže i kdyby došlo na nejhorší a ztratili jsme server a klasické zálohy, prakticky nic se neděje. Můžeme klidně říct: „server je teď u Karla a změny posílejte k němu“ – tým může plynule pokračovat v práci. Jednak nepřijdeme o žádná data a jednak neztratíme čas čekáním na obnovu serveru.
• Vlastní větve – distribuované systémy jsou velice užitečné při vývoji svobodného softwaru. Např. se nám líbí nějaký projekt a chceme v něm něco vylepšit. Jednoduše si naklonujeme úložiště a pracujeme nad touto kopií – nejsme ochuzeni o verzování, máme svoji vlastní historii změn. Odpadá tak administrativa a vyřizování práva zápisu do centrálního úložiště, nemusíme se ani nikoho ptát. Když uděláme kus práce, pošleme původním autorům odkaz na naše úložiště a když se jim naše práce bude líbit, můžou ji přijmout a začlenit pomocí verzovacího systému do hlavní větve. Ani jedna strana nemusí mít k té druhé právo zápisu – každý si verzuje na svém vlastním písečku a v případě zájmu se změny sloučí.
• Modernější systémy – jelikož jsou distribuované systémy mladší, mohli se poučit z chyb svých předchůdců nebo využít modernějších technologií a postupů. Kromě očekávatelného vyššího výkonu a robustnosti nás potěší i různé drobnosti – např. to, že složku .hg, .git nebo .bzr máme v každém úložišti jen jednou, zatímco .svn se nám vždy rozlezlo i do všech podadresářů, což komplikuje např. nasazení aplikace, protože tyto adresáře musíme filtrovat. Šikovnější je také práce s větvemi a štítky. Přestože i starší systémy uchovávají jen rozdíly a vytvoření větve nebo štítku téměř nic nestojí, v pracovní kopii např. v Subversionu se objevují soubory ze všech větví najednou – obvykle tu máme: /trunk (hlavní větev, kmen), /tags (štítky) a  /branches (větve). Na straně klienta tak máme všechny soubory v několika kopiích, což jednak může zabírat dost místa a jednak musíme projekt v IDE nebo v editoru otevírat v různých adresářích. V modernějších systémech jsou soubory pořád na stejném místě a mezi jednotlivými větvemi nebo štítky se přepínáme (soubory se aktualizují, ale jsou pořád ve stejném adresáři).
• Více scénářů práce – zatímco u centralizovaných systémů je možný prakticky jen jediný scénář práce (viz první obrázek), u distribuovaných systémů máme možnosti daleko širší. Kromě nouzových scénářů (jako prohlášení některé pracovní stanice za server) můžeme díky rovnocennosti jednotlivých uzlů vymyslet i další uspořádání (viz níže).

Možná se teď ptáte, jestli jsou distribuované systémy jen skvělé a bezchybné, nebo jestli mají oproti svým centralizovaným příbuzným i nevýhody – nějaké se najdou:

• Mírně vyšší složitost – Když jsem v jednom týmu zaváděl Subversion, některým uživatelům chvíli trvalo, než si zvykli, že nepracují se sdíleným diskem a že provedené změny se na serveru neobjeví hned po uložení souboru, ale až po tom, co odešlou změny (commit). U distribuovaných systémů je situace složitější ještě o jeden krok – i když uživatel udělá commit a hezky si pojmenuje verzi, ostatní jeho práci stále nevidí, dokud jim ji nezpřístupní pomocí push (nebo si ji oni nestáhnou pomocí pull). Pokud by to uživatelům činilo potíže, je v některých systémech možné svázat commit a push do jednoho kroku a „emulovat“ tak centralizovaný verzovací systém.
• „Nehezká“ čísla verzí – Zatímco u Subversionu můžeme říct: „Stáhni si verzi 336, tam už je chyba opravená“ u distribuovaných systémů to říct nemůžeme – resp. můžeme, ale není zaručeno, že budeme mít oba tu stejnou verzi č. 336. Číslování (na které se můžeme spolehnout) zde není tak hezky lineární a označení verze vypadá spíše nějak takto: c39a2d3cb6d2.
• Zamykání souborů – zatímco v takovém Subversionu můžete zamknout určité soubory a tím dát kolegům jasně najevo: „teď na tom pracuju, nehrabte mi do toho“ (tzv. model zamknout-upravit-odemknout), v distribuovaných verzovacích systémech nic takového nelze – každý vývojář má svoji větev (resp. kompletní úložiště) a v něm si může dělat, co chce, nikdo mu „zvenku“ nezamyká jeho soubory – případné problémy se řeší až při slučování větví – tzv. model zkopírovat-upravit-sloučit (merge).

Tyto nevýhody nejsou nijak zásadní a neměly by vás odradit od distribuovaných verzovacích systémů, nicméně je dobré o nich vědět.

Více scénářů práce

U distribuovaných systémů se nemusíme omezovat na klasické uspořádání server-klienti, ale pravděpodobně s ním stejně začneme:

Vzdálené úložiště bude společný server a každý vývojář bude mít na svém počítači místní úložiště (kompletní historie změn bude uložena v adresáři .hg, .git nebo .bzr případně jiném podle použitého systému) pracovní kopii pak tvoří soubory větve, nad kterou aktuálně vyvíjíme.

Po postoupení změn (commit) vzniká verze – sada změn (changeset) a vše se zatím odehrává na našem počítači v příslušném adresáři začínajícím tečkou. Teprve po odeslání změn (push) se naše práce objeví na serveru. Pokud jsme tedy zvyklí na Subversion a vyhovuje nám, uděláme vždy commit a hned po něm push a nic moc se pro nás nemění.

Jak jsme si ale řekli, máme i jiné možnosti. Z počítače na obrázku označeného jako „vzdálené úložiště“ můžeme třeba odesílat změny (push) na zálohovací server, nebo naopak ze zálohovacího serveru provádět pull – je jen na nás, odkud tu akci budeme chtít provádět. Kromě zálohovacího serveru můžeme mít také úložiště pro veřejnost – uživatelé tak svým stahováním nebudou zatěžovat server, na kterém pracují naši vývojáři.

Když některý vývojář zpřístupní ostatním svoje úložiště (přes SSH, HTTP, sdílený disk…), můžou si ostatní stahovat změny (pull) nebo mu naopak přispívat (push), aniž by změny musely projít přes centrální úložiště. To nakonec nemusíme mít vůbec – každý pracuje na svém a občas se synchronizují.

Scénář práce resp. uspořádání úložišť a tok změn mezi nimi si teď můžete vymyslet podle svého vkusu a fantazie. Ispirací vám budiž scénáře popisované v příručkách k jednotlivým systémům. Přičemž platí, že scénář nebo postup popisovaný u jednoho z distribuovaných systémů půjde většinou uplatnit i u jiného – takže se rozhodně nebojte podívat se ke „konkurenci“:

• Git: Any Workflow
• Git: Distributed Workflows
• Bazaar Workflows
• Mercurial: Learning Mercurial in Workflows
• Monotone: Network Service Revisited
• Darcs: Distributed development with one primary developer
• GNU Arch: Collaborating With Other People

Jedním z možných scénářů je např. „správce integrace“ – v tomto případě správce (pověřený člen týmu, zkušený vývojář) stahuje změny od jednotlivých členů, kontroluje kód a schválené změny postoupí opět do jakéhosi „centrálního“ úložiště – a z něj si členové stáhnou změny ostatních (ale sami tam zapisovat nemohou).

Dnes používané DVCS

Mercurial, Git a Bazaar tvoří asi nejznámější a nejpoužívanější trojici. Další systémy z této kategorie jsou: Monotone, Darcs, Fossil a GNU arch. Následující programy vznikly přibližně před pěti lety a mají k sobě velmi blízko – jak svojí koncepcí, tak svými kvalitami.

Mercurial

Mercurial (hg) je dílem vývojáře Matta Mackalla a společnosti Selenic. Je snadné se tento systém naučit a používat ho. Je napsaný v Pythonu (binární diff je implementovaný v jazyce C). Není problém ho provozovat na různých platformách. A k dispozici je i řada zajímavých rozšíření. Mercurial je svobodný software vydaný pod licencí GNU GPLv2.

Kdo např. používá Mercurial: OpenJDK, Netbeans, Mozilla, GNU Octave, OpenOffice.org, Xen, Dovecot.

Git

Původním vývojářem Gitu není nikdo menší než Linus Torvalds, autor Linuxu. Dnes ho v počtu commitů do Gitu předběhli Junio C Hamano a Shawn O. Pearce. Git byl vytvořen jako náhrada proprietárního BitKeeperu, který se do té doby používal pro verzování linuxového jádra. Je napsaný v jazyce C, Bashi a Perlu. Nabízí prakticky neomezené možnosti, byť někdy za cenu trochu složitějšího ovládání. Stejně jako Mercurial je i Git licencovaný pod GNU GPLv2.

Kdo např. používá Git: Linux (jádro), Amarok, Gimp, PostgreSQL, GNOME, VLC.

Bazaar

Autorem Bazaaru (bzr) je Martin Pool a vývoj sponzoruje firma Canonical (Ubuntu). Je napsaný převážně v jazyce Python. Klade velký důraz na uživatelskou přívětivost a disponuje pěkným GUI. Stejně jako předchozí dva systémy i Bazaar je vydaný pod GNU GPLv2.

Kdo např. používá Bazaar: Ubuntu, GNU GRUB, Inkscape, Squid, Stellarium, GNU Wget.

Jak si vybrat verzovací systém

Ještě než začnete přemýšlet, který verzovací systém je ten nejlepší, je třeba si přiznat, že většinou si nebudeme moci vybírat. Když se budeme chtít zapojit do vývoje nějakého svobodného softwaru nebo se nechat někde zaměstnat, budeme se muset přizpůsobit tomu, co se v daném týmu používá. Hodí se proto umět základy každého systému (alespoň těch tří nejpoužívanějších). Základní principy jsou naštěstí dost podobné – a ten zbytek se naučíte za chodu.

Pokud jsme v roli šéfa týmu nebo samostatného vývojáře, tak si můžete vybírat prakticky libovolně. Ani zde ale nejde určit nějaký „jeden nejlepší verzovací systém“. Situace je poměrně vyrovnaná. Pravděpodobně tak pro nás nebudou až tak důležité vlastnosti systému samotného, jako spíš jeho podpora v používaném IDE, editorech, možnost integrace s dalším softwarem (správa chyb a požadavků, testování, průběžná integrace atd.), nebo znalosti a preference ostatních členů týmu.

Následující obrázek se snaží zachytit velikost pozitivních změn, přínosů plynoucích z přechodu na „vyšší“ technologii. Za nejhorší možnou formu spolupráce můžeme považovat posílání si souborů e-mailem – zde je téměř nemožné zachovat si v souborech pořádek a zároveň duševní zdraví, neustále budeme trpět např. problémy s tím, že analýza-1.2.3.xmi která přišla mailem, je „trochu novější“ soubor než analýza-1.2.3.xmi, kterou máme zrovna na disku… nebo není, ale to nikdo neví. Trochu si pomůžeme, když si přestaneme posílat e-maily a pořídíme si nějaký sdílený disk – konečně všichni vidíme ty stejné soubory a není v tom takový guláš. Ale zase se nám stane, že „Pepa něco upravoval, ale Honza tam mezitím uložil svoji verzi a Pepova práce je teď v čudu“ a podobné nepříjemnosti.

Největší pokrok uděláme, když zavedeme verzovací systém – a to jakýkoli. Odpustíme protentokrát posměšné komentáře jak je ten Subversion hloupý, nebo ten CVS nemožně zastaralý – i tyto systémy nám výrazně pomůžou a ušetří práci. V některých týmech se CVS používá dodnes a jsou za něj rádi.

Dalšího poměrně velkého pokroku dosáhneme přechodem od centralizovaných verzovacích systémů k těm distribuovaným. Změnou v rámci této skupiny si už pomůžeme minimálně nebo vůbec – takže hádat se, zda je lepší to či ono je celkem zbytečné. Ať už si vyberete Mercurial, Git nebo třeba Bazaar, neuděláte chybu. Nesmíme zapomínat na to, že tyto systémy jsou v první řadě nástrojem, nikoli cílem našeho snažení – tím je vývoj softwaru případně jiná činnost.

Navíc výběr verzovacího systému není nic jako „manželství na celý život“ – máme poměrně dobré možnosti konverze mezi jednotlivými systémy. Např. pomocí příkazu:

$ hg convert pokus123

vytvoříme z gitovského projektu pokus123 projekt v mercurialu (vznikne nám nová složka pokus123-hg) a to včetně všech větví (branches) a štítků (tags). Připravit se o historii naší práce je tedy zcela zbytečné (totéž platí i pro přechod z centralizovaných VCS). Vždy je dobré konvertovat staré úložiště a ne jen zkopírovat poslední verzi do toho nového.

Závěr

Dnes jsme se seznámili s obecnými vlasnostmi distribuovaných verzovacích systémů a uvedli si pár důvodů, proč je používat místo těch centralizovaných. Po tomto teoretickém úvodu se v následujících dílech seriálu podíváme podrobněji na jednotlivé systémy (příště Mercurial a v dalších dílech přijde řada na Git a Bazaar), povíme si o jejich odlišnostech a ukážeme si praktické používání.