Podstawową funkcjonalnością systemu kontroli wersji jest umożliwienie współpracy, edycji i udostępniania danych. Różne systemy korzystają z różnych strategii osiągnięcia tego celu. Ważne jest, aby zrozumieć te strategie. Po pierwsze, to pomoże Ci porównać i skontrastować istniejące systemy kontroli wersji, w przypadku, gdy napotkasz inne systemy podobne do Subversion. Poza tym, pomoże Ci to bardziej efektywnie wykorzystywać Subversion, ponieważ właśnie ten system obsługuje kilka różnych strategii.
Wszystkie systemy kontroli wersji mają zasadniczo ten sam problem: w jaki sposób system powinien pozwalać użytkownika zapisywać zmiany bez nadpisania zmian wprowadzonych przez innych użytkowników?
Rozważmy scenariusz widoczny w Rysunek 1.2, „Problem do uniknięcia”. Załóżmy, mamy dwóch współpracowników, Harry i Sally. Każdy z nich decyduje się jednocześnie edytować ten sam plik w repozytorium. Jeśli Harry wyśle swoje zmiany jako pierwszy, to możliwe, że Sally przypadkowo nadpisze je bo sama ma plik wcześniejszy bez zmian. Oczywiście zmiany są zapisywane i Harry ma możliwość odzyskania swojej wersji pliku. Jednak w najnowszej wersji pliku jego zmiany nie są uwzględnione. Jest to z pewnością sytuacja, którą chcemy uniknąć!
Wiele systemów kontroli wersji używa modelu zablokuj-modyfikuj-odblokuj do rozwiązania problemu wielu autorów nadpisujących swoje zmiany. W tym rozwiązaniu tylko jeden użytkownik może wprowadzać zmiany do pliku. Ten mechanizm jest realizowany przez system blokad. Harry musi „zablokować” plik przed tym jak będzie mógł wprowadzać zmiany. Jeśli Harry ma zablokowany plik, Sally nie może zablokować go też, a zatem nie może dokonać żadnych zmian w pliku. Wszystko co może zrobić to odczytać plik i czekać na Harry, kiedy skończy swoją pracę i zwolni blokadę. Po odblokowaniu pliku przez Harry, Sally może zablokować i wprowadzić zmiany. Rysunek 1.3, „Metoda blokuj-modyfikuj-odblokuj” przedstawia tą metodę.
Problem z metodą blokuj-modyfikuj-odblokuj jest to, że jest restrykcyjna i często blokuje się innych użytkowników:
-
Blokowanie może powodować administracyjne problemy. Czasami Harry zablokuje plik, a następnie zapomni o tym. Tymczasem Sally, wciąż czeka, na możliwość zablokowania i edycji tego samego pliku, a jej ręce w tym przypadku są związane. Dodatkowo Harry jedzie na urlop. Teraz Sally musi wysłać do administratora prośbę o ściągnięcie blokady. Sytuacja kończy się niepotrzebnie straconym czasem i opóźnieniami.
-
Niepotrzebnie blokowany cały plik. Co w przypadku, jeśli Harry chce zmienić początek pliku tekstowego, Sally natomiast chce edytować koniec tego samego pliku? Zmiany te nie „nachodzą” na siebie. Mogliby edytować plik jednocześnie, a zmiany mogłyby być automatycznie połączone. Nie ma potrzeby w tej sytuacji zakładania blokady na plik.
-
Blokowanie może stworzyć fałszywe poczucie bezpieczeństwa. Załóżmy, że Harry blokuje plik A i edytuje go, a Sally jednocześnie blokuje i edytuje plik B. Ale co, jeśli A i B zależą od siebie nawzajem, a zmiany dokonane w każdej są semantycznie niezgodne? Nagle A i B nie działają już razem. System blokad był niezdolny do zapobiegnięcia problemu jeszcze dodatkowo dostarczając fałszywe poczucie bezpieczeństwa przed wystąpieniem takiego problemu. Dla Harry i Sally jest łatwo wyobrazić sobie, że poprzez nałożenie blokady na plik zaczynają wykonywać bezpieczną atomową transakcję i że nie muszą już między sobą uzgadniać zmian, które chcą wprowadzać, a mogą być niezgodne ze sobą. Blokowanie często staje się substytutem realnej komunikacji.
Subversion, CVS i wiele innych systemów kontroli wersji używa metody kopiuj-modyfikuj-scal jako alternatywę dla metody blokowania plików. W tym modelu każdy klient użytkownika łączy się z repozytorium i tworzy kopie roboczą - lokalne odwzorowanie plików i katalogów z repozytorium. Użytkownicy mogą następnie modyfikować i edytować jednocześnie swoje kopie robocze. Na koniec prywatne wersje użytkowników są scalane w jedną ostateczną wersję.
Dla przykładu. Powiedzmy, że Harry i Sally kopiują repozytorium tworząc swoje kopie robocze. Pracują równocześnie nad tym samym plikiem A. Sally zapisuje jako pierwsza swoje zmiany do repozytorium. Kiedy Harry próbuje zapisać swoje zmiany po Sally, repozytorium informuje go, że jego plik A jest nieaktualny. Innymi słowy, plik A od ostatniego pobrania zmienił się. Dlatego Harry prosi swojego klienta Subversion o scalenie jego zmian z aktualnym plikiem w repozytorium. Rysunek 1.4, „Metoda kopiuj-modyfikuj-scal” i Rysunek 1.5, „Metoda kopiuj-modyfikuj-scal (ciąg dalszy)” przedstawiają ten proces.
Ale co w przypadku gdy podczas scalania zmiany będą na siebie nachodzić? Sytuacja ta nazywa się konfliktem, a to zazwyczaj nie duży problem. Kiedy Harry łączy klientem svn swoją kopie roboczą z repozytorium, jego plik staje się oflagowany jako będący w konflikcie. A on sam będzie mógł wyświetlić fragmenty pliku będące w konflikcie i zdecydować jak wprowadzić zmiany by konflikt został zażegnany. Należy pamiętać, że oprogramowanie nie może automatycznie rozwiązać konflikty, tylko ludzie są zdolni do zrozumienia i dokonania niezbędnych inteligentnych wyborów. Kiedy Harry rozwiąże konflikt — zazwyczaj po dyskusji z Sally, będzie mógł bezpiecznie zapisać plik do repozytorium.
Model kopiuj-modyfikuj-scal może wydawać się nieco chaotyczna, ale w praktyce, to działa bardzo sprawnie. Użytkownicy mogą pracować równocześnie, nie czekając na siebie. Kiedy pracują jednocześnie nad tymi samymi plikami okazuje się, że konflikty są sporadyczne a zazwyczaj zmiany nie „nakładają” się, dzięki czemu mogą być automatycznie scalone. Czas poświęcony na rozwiązanie konfliktu jest znacznie krótszy niż czas poświęcony na czekanie w metodzie blokowania plików.
W końcu wszystko sprowadza się do jednego zasadniczego czynnika: komunikacja między użytkownikami. Kiedy użytkownicy komunikują się słabo, można zauważyć zarówno syntaktyczny i semantyczny wzrost konfliktów. Żaden system nie wymusi na użytkownikach komunikacji między sobą. Więc nie ma sensu usypiania fałszywie poczucia bezpieczeństwa, że system blokowania będzie jakoś zapobiegać konfliktom; w praktyce, wydaje się hamować bardziej niż cokolwiek innego.