System kontroli wersji
Tworzenie kodu, tekstu i tym podobnych na komputerze jest często procesem iteracyjnym, w wyniku którego pojawiają się kolejne wersje ostatecznego dzieła. Nierzadko też trzeba wrócić do pewnego momentu w czasie i zacząć pracę w innym kierunku (np. żeby przetestować inny wariant rozwiązania w kodzie). A potem można chcieć kontynuować prace tam, gdzie się je porzuciło.
Takie poruszanie się w przód i w tył w historii danego produktu jest znacząco ułatwione właśnie dzięki systemom kontroli wersji (RCS - Revision Control Systems). Będzie to jakiś rodzaj bazy danych (o różnym stopniu skomplikowania, w zależności od potrzeb), w której przechowywane będą wszystkie zmiany wprowadzone w cyklu tworzenia produktu. Oprócz samych zmian, przechowywane są również metadane dotyczące czasu ich wprowadzenia, lokalizacji w tekście, ewentualnie komentarze.
Typowe użycie
Typowym schematem korzystania z systemu kontroli wersji może być ten:
-
Stworzenie projektu objętego systemem kontroli wersji (utworzenie głównych rekordów w RCS)
-
Praca nad wersją
2.1. checkout: pobranie odpowiedniej wersji do lokalnego systemu
2.2. edytowanie wersji dokumentu (bezpośrednia praca na wersji lokalnej, RCS nie bierze udziału)
2.3. commit: zatwierdzanie bieżącej wersji (zapisanie stanu do RCS)
2.4 push: (w przypadku systemów ze zdalnym repozytorium) przesłanie aktualnej wersji wraz z metadanymi na serwer globalny
Czynności opisane w kroku 2. mogą dotyczyć zawsze bieżącej (najświeższej) wersji dokumentu, ale możliwe jest też odtworzenie wersji poprzedniej (revert), utworzenie chwilowej kopii do drobnych prac (branch), czy stworzenie zupełnie innej linii rozwojowej (fork).
W miarę zagłębiania się w projekt może się okazać, że pewne wersje stają się głównymi, jeszcze inne nabierają osobnych funkcjonalności tak, że stają się odrębnym produktem. W przypadku pracy wielu programistów, każdemu z nich mogą być przypisane indywidalne wersje kodu, które następnie zostaną złączone w jeden, działajacy program.
Np. coś ala tutaj
Lokalizacja i współdziałanie
Patrząc na systemy kontroli wersji pod kątem miejsca, gdzie są ulokowane, można mówić o trzech wariantach.
Lokalne systemy kontroli wersji działają w jednym systemie komputerowym i śledzą zmiany w plikach, zapisując je w sposób przyrostowy (czyli tylko różnice). Dzięki temu możliwe jest odtworzenie stanu każdego śledzonego pliku. Awaria systemu wersjonowania (bazy danych) typowo kończy się utratą wszystkich informacji historycznych. Wykorzystanie tego mechanizmu nie daje możliwości współpracy wielu programistów, o ile nie są wykorzystywane inne środki, nie zintegrowane z samym systemem RCS.
Scentralizowane systemy kontroli wersji realizują typową architekturę klient-serwer, gdzie serwer przechowuje bazę danych o wersjonowanych plikach, a klienci odpytują tę bazę i pobierają żądaną wersję projektu. Po skończonej pracy klienci oddają swoją wersję na serwer, który aktualizuje odpowiednie zapisy w bazie danych. Jako że w tym modelu może działać wielu klientów, widać, że tego typu system kontroli wersji musi rozwiązywać m.in. takie problemy jak ustalanie, która wersja jest najnowsza (gdy kilku klientów oddaje swoje wersje jednocześnie), a także jaką wersję przyjąć w przypadku konfliktu (gdy klienci edytowali ten sam element projektu i ich rezultaty się różnią). Jako że serwer przechowuje wszystkie dane dotyczące wersji, w przypadku jego awarii tracone są wszystkie elementy projektu poza tymi wyeksportowanymi do klientów. Z drugiej strony, wykorzystanie architektury klient-serwer umóżliwia współpracę wielu osób nad jednym projetem.
Rozproszone systemy kontroli wersji charakteryzują się dodatkowym stopniem złożoności systemu: repozytorium nie jest przechowywane na jedym serwerze, lecz jest kopiowane na inne. Serwery między sobą synchronizują bieżący stan projektu, co umożliwia skuteczną pracę nad nim wielu osobom, a samo rozproszenie informacji ułatwia przywrócenie pełnej wersji projektu w przypadku awarii jednego serwera.
Interfejsy do RCS
github, gitlab ... (?)