středa 14. listopadu 2007

Distribuované CVS? Proč ne

Píšu CVS, ale myslím ve skutečnosti distribuovaný version control systém (zkráceně DVCS).

CVS, SVN a další systémy jsou centralizované. Je pouze jedna lokální repository, ke které se přistupuje. Pokud chcete udělat změnu, potřebujete patřičná přístupová práva. Pokud chcete dělat paralelní vývoj, např. potřebujete současně spravovat hlavní vývojovou linii a zároveň historickou (fixy), musíte si v těchto systémech udělat (fork) větev (branch). Rozvětvení je jedinou možností jak paralelně pracovat nad jednou repository. Pokud potřebujete spojit práci ve dvou větvích musí dojit k jejich spojení (merge). Každý kdo to kdy dělal, určitě ví jak je to bolestná operace.

Jednou z typických situací, která se špatně řeší s nástroji jako CVS, je případ kdy dva vývojáři pracují nad jednou sadou souborů paralelně, a v určitý okamžik by potřebovali změny od sebe navzájem. Mají dvě možnosti: manuálně si vyměnit změny a aplikovat je a nebo změny promítnout přímo do repository. Obě možnosti jsou bolestivé. V prvním případě je to především nutnost udělat manuální diff nad změnami a následně jeho aplikaci, což je činnost v pravdě nešikovná. V druhém případě může dojít k zanesení neodladěných změn, které mohou dočasně způsobit problémy (centrální repository byla použita pouze pro synchronizaci mezi vývojáři).

Distribuovaný version control systém (DVCS)

Předchozí povídaní mi umožnilo vytvořit oslí můstek k DVCS. Distribuované verzovací systémy se od těch centralizovaných liší v tom, že namísto jedné centrální repository může existovat repositoří více. Způsob práce se liší od centralizovaného přístupu v tom, že vývojář si může lokálně zkopírovat repository a nad ní začít pracovat. Může dělat commit, update a další dobře známe operace. Tyto změny jsou propagovaný do jeho lokální repository. Ve chvíli kdy se rozhodne, že jeho repository resp. stav práce je v patřičném stavu, provede se merge jeho lokální repository a jiné repository.

Na našem předchozím příkladu si popíšeme jak je možné jej řešit s DVCS. Máme hlavní vývojovou repository. Z ní si udělá vývojář číslo jedna lokální kopii, vývojář dva udělá to samé. Ve chvíli kdy se potřebují synchronizovat, využijí DVCS merge mezi svými lokálním repositořemi. Všechny změny mají u sebe lokálně. Po dohodě může jeden z nich pronést změny (klasický commit) do centrální vývojové repository.

Možné modely práce s DVCS popisuje článek Workflows, který je součástí dokumentace DVCS systému Bazaar. Článek doporučuji k nakouknutí, protože vše je pěkně ilustruje na obrázcích. Modely v něm popsané jsou následující:

  • Solo
  • Partner
  • Centralized
  • Centralized with local commits
  • Decentralized with shared mainline
  • Decentralized with human gatekeeper
  • Decentralized with automatic gatekeeper

Mě osobně zaujaly poslední dva a vysvětlím proč. Decentralized with human gatekeeper je velice vhodný pro open source projekty. Představte si situaci, kdy pracujete na open source projektu, ale nemáte práva k pronesení změn. V případě DVCS si správce open source projektu vytáhne změny z vaší lokální repository, provede merge a pokud je vše v pořádku, pronese je do centrální repository. Tento přístup razí například Jason Van Zyl jakožto hlavní vývojář projektu Maven viz email ve vývojářském mailling listu (GIT je konkrétní DVCS).

For anyone who wants to make changes to Maven but doesn't have access I am going to setup a GIT repository to try and enable some distributed development. After using GIT for about a week I'm having a hard time using SVN but obviously we're not going to be switching anytime soon. But for anyone who has patches or wants to try and work with me to get changes in I am going to try this method of publishing Maven as a GIT repository which will allow anyone to clone the repository and work on any changes you like in a controlled way. Once you clone you can commit changes to your own copy of Maven and do whatever you like. Then in order for me to see your changes I can simply pull from your originally cloned repository to a branch on my side and merge. Merging is sooooooo easy with GIT. So easy in fact that it makes you wonder how SVN got it so wrong and makes it so painful compared to GIT.

Obdobný model se používá například pro Linuxové jádro. Filozofii DVCS pěkně popisuje Lins Torvalds v mailu clarification on git, central repositories and commit access lists, kde se snaží vysvětlit přínos DVCS pro vývoj desktopového systému KDE.

Druhý model práce s DVCS, nazvaný Decentralized with automatic gatekeeper, mě zaujal z toho důvodu, že je v něm integrován takzvaný delayed commit. Tedy commit, který projde až při splnění určitých podmínek, například projdou testy, někdo udělá review apod. Tento přístup se hodí v čase před releasem, kdy je potřeba každou změnu důkladně zvážit, aby nebyla zavlečena nějaká chyba.

each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper (e.g. PQM) has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once passed review, either the original author or the reviewer asks the gatekeeper to merge it, depending on team policies. The gatekeeper does a merge, a compile, and runs the test suite. If the code passes, it is merged into the mainline.

Decentralized with automatic gatekeeper

DVCS má jak výhody, tak nevýhody a asi určitě se nehodí pro všechny typy projektů. Na druhou stranu musím dodat, že i distribuované verzovací systémy se dají používat stejným způsobem jako centralizované a do těch centralizovaných se naopak začínají přidávat vlastnosti těch decentralizovaných (SVN a lokální commit). Pokud vás DVCS přístup zaujal, pak bych doporučoval k přečtení ještě následující dva články z ruky spoluautora SVN.