Distribuované verzovací systémy – úvod (1)

25. 1. 2011 | František Kučera

Články - Distribuované verzovací systémy – úvod (1)  

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 – nejprve se na ně tedy podíváme teoreticky a v dalších dílech se budeme věnovat prakticky jednotlivým implementacím.

Obsah

• Trocha historie
• Co jsou verzovací systémy a k čemu jsou dobré
• Proč distribuované verzovací systémy

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 samy 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 objevují 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 nejvě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ím souborů z poštovního klienta na disk a opětovným vkládáním 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ětve 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ší, mohly 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.

---

Ve čtvrtek budeme pokračovat hlubším představením distribuovaných verzovacích systémů a tím bude úvod uzavřen.

Seriál Distribuované verzovací systémy (dílů: 3)

První díl: Distribuované verzovací systémy – úvod (1), poslední díl: Distribuované verzovací systémy: Mercurial – úvod.
Následující díl: Distribuované verzovací systémy – úvod (2)