Rozproszone zarządzanie wersjami

Wprowadzanie

Określenie rozproszony dotyczy sposobu organizacji repozytorium. Zamiast stosowanego w tradycyjnych systemach pojedynczego repozytorium mamy wiele równoważnych repozytoriów, z których każdy zawiera pełną historię projektu.

Programista mający pracować nad projektem tworzy nową tego typu kopię a następnie wszelkie operacje (od przeglądania historii po oddawanie zmian) może realizować lokalnie. Równie łatwo można tworzyć wydzielone kopie służące rozwijaniu eksperymentalnych wersji kodu czy utrzymaniu poprzednich dystrybucji (odpowiednik branch-y w systemach typu CVS, ale znacznie, znacznie wygodniejszy w użyciu).

Pojawia się pytanie o sposób przekazywania zmian między repozytoriami. Stosowany jest model commit-and-merge (patrz artykuł o konfliktach), tj. poprawki są najpierw zatwierdzane a dopiero potem łączone. Programista pracuje na swojej kopii, realizuje zmiany i zatwierdza je, a połączenia z zmianami dokonanymi przez innych dokonuje w odpowiednio wybranych momentach.

Zaczęło to brzmieć bardzo ogólnikowo. Dla wolących konkrety - przykład jak wyglądają i działają komendy Mercuriala.

Trzeba podkreślić, że narzędzia DVCS bardzo ułatwiają proces powstawania rozgałęzień kodu i łączenia zmian - nie ma mowy o powtórnym połączeniu tej samej zmiany, zawsze wiadomo co z czym i kiedy zostało połączone, zawsze wiadomo jakie mamy aktualnie niezależne rozgałęzienia kodu, samo rozgałęzienie powstaje po prostu w efekcie zatwierdzenia zmian, podczas łączenia umiejętnie są wykorzystywane narzędzia graficzne prezentujące różnice.

Ciekawostka techniczna: standardową metodą identyfikowania zmian jest wykorzystanie sum kryptograficznych (wyliczonych z commitowanych danych). Zapewnia to poprawną identyfikację pakietu zmian niezależnie od sposobu jego pobrania, także przy pracy z wykorzystaniem wielu repozytoriów, przesyłaniem poprawek w formie patchy itp.

Prostą praktyczną zaletą DVCSów jest możliwość bezproblematycznej pracy na laptopie odciętym od sieci.

Modele organizacyjne

W realnych projektach grupę repozytoriów trzeba jakoś zorganizować. Narządzia DVCS dają tu swobodę.

Kilku programistów może pracować używając każdy swojego repozytorium i przekazując sobie zmiany ad hoc bez formalnego procesu.

Duży projekt zastosuje raczej strukturę gwiaździstą, w której poprawki indywidualnych programistów są łączone w jednym lub kilku eksperymentalnych repozytoriach, po przetestowaniu i przeglądzie trafiają do repozytorium oficjalnej dystrybucji, a całość mogą też uzupełniać dodatkowe repozytoria wspierające utrzymanie starszych wersji.

Wreszcie, DVCS-y dają się łatwo używać w zastosowaniach indywidualnych, gdzie aby zacząć wersjonować jakiś katalog, wystarczy wydać jedną prostą komendę (nie trzeba konfigurować żadnego rodzaju serwera), jest to równie łatwe jak wykorzystywanie RCS czy SCCS (z większymi możliwościami, choćby obsługą zmian nazw plików). Przy tym tego typu projekt można w dowolnym momencie rozproszyć, dzieląc go z innym programistą czy zespołem.

Dokumentacja systemu Bazaar zawiera przyjemny ilustrowany artykuł na temat różnych modeli pracy.

Mercurial

Mercurial jest ... prosty. Łatwo zacząć go używać, łatwo nauczyć się bardziej zaawansowanych operacji, nie trzeba przyswajać sobie złożonych pojęć, niewiele jest możliwości popełnienia pomyłek, dostępna jest dopracowana i zrozumiała dokumentacja. Do tego działa sprawnie i wydajnie.

Pewnym ograniczeniem jest dość formalne podejście do modelu DVCS. Nie da się zmodyfikować historii projektu (nawet poprawić starego komentarza o zmianie), właściwie nie ma wsparcia dla projektów dzielących się na podprojekty, dość ograniczone jest wsparcie dla wymuszania konkretnej hierarchii repozytoriów.

Zdecydowanie zachęcam do poznania tego narzędzia, nawet jeśli z takich czy innych przyczyn wybrany zostanie później inny DVCS, Mercurial pozwala bezboleśnie poznać specyfikę tego rodzaju pracy.

Z Mercuriala korzysta wiele znanych projektów, nawet tak dużych, jak OpenJDK czy OpenSolaris.

Najważniejsza dokumentacja:

• Mercurial Book - książka o Mercurialu,
• Mercurial QuickStart i Mercurial Usage - pojedyncze kartki z wykazem kluczowych terminów i poleceń,
• Mercurial Wiki - nieco bałaganiarskie, ale zawierające sporo użytecznych informacji.

Dorzucę też mój przykład jak może wyglądać używanie Mercuriala w projekcie.

Bazaar

Bazaar to interesująca próba bycia praktycznym. Oprócz czystego modelu DVCS jest też wspierany scentralizowany styl pracy (dający efekt bardzo zbliżony do pracy z Subversion czy CVS), a także dowolnego rodzaju hybrydy. Są dostępne narzędzia i rozszerzenia wspomagające integrowanie i testowanie zmian, współdziałanie z bugtrackerami itp. No i jest Launchpad, czyli ogólnodostępny serwer pozwalający na publikowanie projektów wersjonowanych przy pomocy Bazaara, proponujący sensowny model pracy z jego użyciem i dający zintegrowane dodatkowe narzędzia. Dokumentacja jest wystarczająca, choć ustępuje dokumentacji Mercuriala.

We wczesnych wersjach Bazaar miewał pewne problemy wydajnościowe, obecnie (min. dzięki pewnym zapożyczeniom od GIT-a) działa wystarczająco sprawnie.

Bazaar jest szczególnie wart rozważenia w przypadkach w których przy wykorzystywaniu wybranych możliwości DVCS chcemy zachować elementy scentralizowanej struktury (albo gdy chcemy złagodzić migrację z narzędzia monolitycznego, wprowadzając DVCS-owe konwencje po trochu). W szczególności może być atrakcyjną propozycją dla firm.

Bazaar jest standardowym narzędziem dla projektów związanych z Ubuntu i Launchpadem (rozwija go firma Canonical, autorzy Ubuntu), jest też stosunkowo popularny wśród projektów open-source.

Dokumentacja:

• Bazaar Documentation - dobrze zorganizowany pakiet dokumentacji Baazara.

GIT

GIT - projekt pierwotnie stworzony przez Linusa Torvaldsa na potrzeby zarządzania kodem jądra Linuksa - to chyba najbardziej obecnie znany DVCS. Działa bardzo wydajnie, ma też szczególnie rozbudowaną obsługę rozmaitych scenariuszy integrowania poprawek (zarządzanie kodem Linuksa ciągle jest kluczowym zastosowaniem tego narzędzia).

Podstawowym problemem jest że GIT jest dość trudny, ciągle jest to przede wszystkim projekt typu guru dla guru (tworzony przez inteligentnych programistów do obsługi skomplikowanych zastosowań). Można tu zrobić bardzo wiele, można obsłużyć nietypowe i skomplikowane przypadki, zarazem jednak nie jest oczywiste jak postępować w prostych zastosowaniach, wiele operacji działa nie do końca intuicyjnie, a chcąc zrozumieć działanie GIT-a szybko napotykamy na skomplikowane szczegóły techniczne (ot, lista terminów na które od razu nadziałem się próbując swego czasu bliżej poznać GIT-a - rebase, index, revtree, reset. refs, rev-list,...).

Inny kłopot to fakt, że GIT ciągle jeszcze jest głównie produktem Linuksowym, wersje dla Windows są kłopotliwe w instalacji i używaniu.

Z drugiej strony, GIT rozwija się bardzo szybko, pracuje nad nim duży i silny zespół, jakość dokumentacji radykalnie się poprawia a typowe schematy użycia upraszczają. Na pewno jest to projekt o wielkim potencjale i wart poznania.

Osobiście radzę, by nie poznawać GIT-a jako pierwszego DVCS-a, lepiej wypróbować najpierw któreś z łatwiejszych narzędzi, a do GIT-a przymierzyć się znając już specyfikę rozproszonej kontroli wersji.

Dokumentacja:

• Official GIT Documentation
• GIT Wiki

Inne możliwości

Powyższe trzy narzędzia wydają się mieć obecnie największy potencjał, nie wyczerpują jednak listy możliwości. Ciekawymi projektami są choćby Monotone (akcent na kryptograficzne podpisywanie zmian a co za tym idzie formalnie weryfikowalną historię projektu), SVK (DVCS zbudowany na bazie Subversion z maksymalnie możliwym zachowaniem podobieństw) i Darcs (przez wiele osób uważany za szczególnie przyjemny i naturalny w użyciu).

Najbardziej znanym komercyjnym narzędziem typu DVCS jest BitKeeper.