Rozproszone systemy kontroli wersji

Z systemami kontroli wersji (w skrócie VCS) zetknął się każdy programista i dla niemal wszystkich jest to oczywiste narzędzie pracy. Dla wielu jednak wciąż jeszcze kojarzą się one z jednym, centralnym miejscem zawierającym zawierającym bazę kodu projektu (czyli repozytorium) oraz z licznymi kopiami roboczymi, nad którymi pracują programiści. Kiedy zaś chcą połączyć swoje zmiany, wówczas wykonują tylko operację znaną jako commit.

Tak jest w systemach typu CVS czy Subversion, ale obecnie sporą popularność zyskały też inne, działające na nieco innej zasadzie. Nazywają się one rozproszonymi (distributed version control system – DVCS) i zgodnie z tym określeniem ich główną cechą jest brak wydzielonego, centralnego repozytorium. Zamiast tego może być ich dowolna ilość, która w rzeczywistych projektach może łatwo urosnąć do setek, a nawet tysięcy. Najczęściej bowiem swoje własne repozytorium ma na przykład… każdy pracujący nad projektem programista.
Obłęd? Niezupełnie. Wszystko opiera się bowiem na operacji synchronizacji dwóch repozytoriów, którą nazywa się – w zależności od punktu widzenia – push lub pull. Push oznacza wprowadzenie poprawek z naszego repozytorium do innego, zaś pull oznacza ściągnięcie zmian z innego repozytorium do własnego. Jak nietrudno zauważyć, operacja ta jest symetryczna. I chociaż techniczne wszystkie repozytoria są równoważne, w praktyce jedno z nich jest zwykle bazą projektu, zawierającą jego “autorytatywną” wersję. Ponadto z każdym repozytorium można też pracować “normalnie”, tj. przy pomocy znanych i lubianych operacji commit i update.

Działanie rozproszonych systemów kontroli wersji

Po co taka zmiana? Przydaje się ona zwłaszcza w dwóch sytuacjach:

• Dla projektów typu open source umożliwia względnie niezależne opracowywanie poprawek do projektów. W tym celu wystarczy sklonować główne repozytorium, a następnie w spokoju pracować nad uzyskanym kodem, korzystając z jego kopii. Chcąc następie uczynić zmiany obowiązującymi, możemy wykonać push – ale tylko wtedy, jeśli mamy do tego prawa. Jeśli nie, możliwe jest stworzenie łatki (patch), zawierającej nasze modyfikacje i przekazania jej osobie zarządzającej projektem. Ta zaś może – zapewne po przetestowaniu zmian na własnej kopii repozytorium – wprowadzić je wreszcie do bazy kodu. Podobny akceptowania poprawek występował w projektach open source już od dawna, ale dopiero rozproszone systemy kontroli wsparły go od strony technicznej.
• Jeśli pracujemy wyłącznie lokalnie nad własnymi projektami, możemy stworzyć sobie takież repozytorium, które będzie przy tym jedynym. Nie synchronizujemy wtedy zmian z żadnym innym repozytorium, ale wciąż możemy korzystać ze standardowych funkcjonalności systemów kontroli wersji.

W średniej skali (takiej, jak przedstawiona na obrazku powyżej) systemy rozproszone sprawdzają się natomiast nieco gorzej – zwłaszcza, gdy częstotliwość zmian jest duża. Wówczas często zachodzi potrzeba łączenia (merge) różnych ścieżek tworzenia aplikacji.

Tym niemniej warto się zainteresować tego rodzaju systemami kontroli wersji, by przekonać się, że poza Subversion też coś istnieje :) Przykładami rozproszonych VCS-ów są np. Mercurcial i Git.

Repozytorium dla każdego

Były takie prognozy, że w Internecie wkrótce nie będzie już prawie niczego za darmo, a za większość usług czy nawet informacji trzeba będzie płacić. W rzeczywistości można obecnie znaleźć w sieci coraz bardziej wyrafinowane i wyspecjalizowane usługi często całkowicie (lub niemal całkowicie) darmowe. Nie chodzi tu już tylko o webhosting czy konto e-mail. Przeciwnie, nietrudno natrafić na oferty skierowane bezpośrednio do… programistów – zawodowców i amatorów.

Istnieją bowiem serwisy, które nieodpłatnie udostępniają swoim użytkownikom repozytoria, na których mogą oni umieszczać swoje projekty. Tak tak, chodzi tutaj o hostowanie systemów kontroli wersji, w szczególności najpopularniejszego: Subversion (SVN). Wystarczy zarejestrować się w jednym z takich serwisów, a otrzymujemy możliwość założenia swojego własnego repozytorium i nadania praw dostępu do niego innym użytkownikom. Obowiązują oczywiście pewne ograniczenia, dotyczące najczęściej ilości miejsca na naszą twórczość lub liczby osób, które możemy zaprosić do współpracy. Na potrzeby własne, szkolne i uczelniane często są one jednak możliwe do zaakceptowania. A jak nie, to pozostają jeszcze wersje płatne – bo nie ma co ukrywać, że to o przyciągnięcie do oferty komercyjnej w całym tym ambarasie chodzi :)

Darowanemu koniowi nie ma co jednak zaglądać za bardzo w zęby. Jeśli bowiem potrzebujemy narzędzia do zorganizowania pracy grupowej (albo nawet swojej własnej) nad niewielkim projektem, to serwisy w rodzaju Beanstalk, XP-Dev czy Assembla mogą być bardzo dobrym rozwiązaniem.

Systemy kontroli wersji

Kiedy nad jednym projektem pracuje więcej niż jedna osoba, nieuchronnie powstaną problemu z synchronizacją kodu napisanego przez różnych programistów. Jeśli wersje utrzymywane i modyfikowane przez poszczególne osoby będą przez jakiś (nawet całkiem krótki) czas odizolowane od siebie, wtedy nieuchronnie się “rozjadą”. Integracja takich kawałków będzie potem bardzo trudna.
Takich problemów nie da się rzecz jasna całkiem uniknąć, ale wymyślono kilka sposobów, które pomagają je rozwiązywać. Wśród nich pewnie najważniejsze są systemy kontroli wersji.

Idea działania takiego systemu jest w miarę prosta. Istnieje mianowicie centralne i ogólnodostępne (czytaj: umieszczone na zdalnym serwerze) miejsce, gdzie składowane są różne wersje kodu projektu – czyli repozytorium. Pracujące nad nim osoby pobierają z niego aktualną wersję, dokonują swoich modyfikacji, a następnie załadowują ją z powrotem (tzw. commit), tworząc w ten sposób nową wersję w repozytorium. Po drodze mogą oczywiście wyniknąć konflikty, jeśli ten sam kod jest zmieniany równocześnie przez dwóch użytkowników; takie niezgodności są wykrywane automatycznie, ale ich rozwiązywanie należy już do programistów. Ponieważ jednak w repozytorium trzymana jest historia wszelkich zmian, zawsze można powrócić do poprzedniej wersji, jeśli coś pójdzie nie tak.
Najpopularniejszym systemem kontroli wersji jest oczywiście CVS (Concurrent Version System), o którym słyszał pewnie każdy. Pośród licznych jego wad największą jest chyba ta, iż jest… wciąż bardzo popularny :) Jest tak mimo tego, że od prawie dekady istnieje znacznie lepszy system o nazwie Subversion (w skrócie SVN), który ma liczne przewagi nad swoim poprzednikiem. Jak choćby to, że potrafi też wersjonować zmiany w strukturze katalogów, lepiej obsługiwać pliki binarne i nie grozić zepsuciem repozytorium, jeśli podczas commitu zdarzy się coś złego z serwerem lub połączeniem.

Jak to często bywa, przyczyną takiego stanu rzeczy jest naturalnie zasiedzenie tudzież przyzwyczajenie. Skoro bowiem tacy giganci jak SourceForge nadal opierają się na CVS-ie, prawdopodobnie jeszcze przez długi czas trzeba będzie radzić sobie z jego niedogodnościami. Jakby sama praca grupowa nie dostarczała wystarczającej liczby kłopotów… ;P