Rozproszone systemy kontroli wersji

2010-10-20 23:10

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.

Tags: , , , ,
Author: Xion, posted under Applications, Programming »


3 comments for post “Rozproszone systemy kontroli wersji”.
  1. Sebas86:
    October 21st, 2010 o 7:42

    Jeszcze jeden fajny aspekt, to łatwość używania. Instalujemy Git’a, inicjujemy repozytorium i już możemy się cieszyć w pełni działającym systemem i to w jednym miejscu. Dla scentralizowanych trzeba zrobić krok więcej i wydzielić osobną przestrzeń na główne repozytorium. Jeszcze jedna fajna sprawa to pełna kopia repozytorium, więc możemy działać na lokalnej maszynie jak na pełnym repozytorium, wysyłać nie w pełni działające poprawki (lokalnie) tak aby mieć nad nimi kontrolę i dopiero później wypchnąć je na zewnątrz w postaci końcowej, która powinna już co najmniej dać się skompilować. Fajną sprawą jest szybkie przełączanie między rozgałęzieniami, więc sytuacje, że siedzę rozgrzebany i nie mogę wypuścić czegokolwiek do prezentacji lub testów się nie zdarzają.

  2. Xion:
    October 21st, 2010 o 14:06

    Kopia repozytorium (tj. kopia kodu w naszym repozytorium) potrafi też zajmować sporo miejsca, więc trzeba o tym pamiętać. A przełączanie między branchami to faktycznie czysta poezja. Przynajmniej nie trzeba tworzyć tej durnej struktury bazowej katalogów (trunk, branches, tags) jak w SVN.

  3. Sebas86:
    November 7th, 2010 o 18:45

    W pełni zgadzam się z uwagą odnośnie miejsca na dysku (bardzo poważny problem dla osób pracujących np. nad grafiką). Na szczęście dla programistów, gdzie zmienia się głównie kod źródłowy i nie wrzuca się zbyt często np. binarnych buildów jest to problem marginalny. :)

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.