Języki

Erudis - your road to knowledge
Przykłady stosowania systemu kontroli wersji

Zastanówmy się co się dzieje jeżeli ktoś potrzebuje powrócić do starszej wersji plików? W takiej sytuacji może on wybrać z repozytorium wersję (np według daty albo etykiety) i zacząć pracę nad nią.

Trochę bardziej skomplikowana sytuacja jest jeżeli potrzebujemy jednocześnie pracować na dwóch wersjach. Będziemy wtedy musieli dokonać rozgałęzienia projektu. Powstaną dwie gałęzie (branch) w których będziemy mogli pracować bez wpływania jedna na drugą. A gdy nadejdzie czas, że będziemy chcieli połączyć te wersje to wtedy będziemy musieli wykonać funkcję Merge.

Rozważmy następujące przykłady.

Przykład A. Tworzymy program wymieniający informację przez sieć po protokole TCP/IP, który szyfruje komunikację algorytmem A. W pewnym momencie czytamy o nowym wspaniałym algorytmie B, który jest szybszy i bezpieczniejszy. Zmiana pliku z implementacją algorytmu to moment. Następnie zaznaczamy zmienione pliki etykietą (label). Program zaczyna działać na nowym algorytmie, mijają dni i tygodnie i nagle okazuje się, że jakiś genialny matematyk wynalazł metodę ataku na algorytm B, która powoduje, że można go złamać w ciągu kilku dni a nawet godzin. Chcemy natychmiast wrócić do algorytmu A. Jeżeli mamy system kontroli wersji to jest to proste: ponieważ zaznaczyliśmy w systemie kontroli wersji zmianę algorytmu, więc albo anulujemy zmiany w pliku z algorytmem, albo kopiujemy poprzedni algorytm z historycznego pliku.

Przykład B. Nasza firma rozwija się i mamy już 3 wersję naszego produktu. Starsze wersje nie są dalej rozwijane, a tu nagle pojawia się klient, który koniecznie potrzebuje poprawek do pierwszej wersji aplikacji.

Jeżeli korzystamy z systemu kontroli wersji to nasze zadanie jest bardzo proste. Odnajdujemy w repozytorium moment w historii produktu, oznaczony jako wersja 1, tworzymy rozgałęzienie, poprawiamy kod, dostarczamy gotowy produkt klientowi i oczywiście inkasujemy należność. Gdy nie używamy SKW to musimy poszukać odpowiedniej kopii zapasowej aplikacji z tego okresu (bo robiliśmy przecież kopie zapasowe każdej wersji, prawda?), następnie poprawiamy znaleziony przez klienta błąd... Jeżeli nie dysponujemy archiwalną kopią kodu, to nasze zadanie staje się niezwykle trudne.

Można sobie zadać pytanie, dlaczego by po prostu nie sprzedać klientowi nowej wersji produktu – otóż często jest to niemożliwe, na przykład ze względu na bezpieczeństwo, inne systemy informatyczne, jakimi dysponuje klient, itd.

Powyższe przykłady opisują jedynie udogodnienia oferowane przez system kontroli wersji. Znacznie poważniejsza sytuacja jest opisana w ostatnim przykładzie.

Przykład C. Nad projektem pracuje grupa programistów. Bardzo często używany jest plik z klasą obsługującą główne okno programu - MainFrm.cpp. Dwóch programistów Jan i Tomasz pracując nad swoimi częściami kodu potrzebowało zmodyfikować plik MainFrm.

Jan jako pierwszy skończył i wstawia plik do głównego repozytorium, Tomasz robi to jako drugi. Jeżeli nie mamy SKW to repozytorium najczęściej będzie wprost w systemie plików, wtedy Jan straci swoje zmiany bo w tym przypadku kto pierwszy ten gorszy. SKW natomiast zasygnalizuje, że istnieje zmieniona wersja i zaproponuje łączenie (Merge) zmian. Co więcej, ponieważ zmiany nie będą anonimowe, to obaj programiści będą mogli uzgodnić swoje poprawki. Niczyja praca nie będzie stracona.

System kontroli wersji broni nas również przed nami samymi. Również w sytuacji gdy Tomasz jest zmęczony i pomimo ostrzeżenia zmusi SKW do nadpisania pliku to cały czas istnieje wersja Jana jako poprzednia. W tym przykładzie system kontroli wersji broni nas również przed uzyskaniem wersji kodu, która nie będzie się kompilowała – nadpisanie czyichś zmian może właśnie doprowadzić do problemów z kompilacją.