Systemy kontroli wersji – Mercurial

Systemy kontroli wersji – Mercurial

Pracowałeś nad większym projektem i bałeś się przystępować do większych zmian w kodzie?

Zaśmiecałeś dysk folderami typu projekt1, projekt2. Wykomentowywałeś duże bloki kodu, żeby dało się je szybko przywrócić jeśli coś przestanie działać? Czas na wprowadzenie systemu kontroli wersji Mercurial!

Rozwiązania tymczasowe

Dzięki doświadczeniu, uwadze i pomysłowości znajdowałeś sposoby na przezwyciężenie tego typu problemów.

Okazuje się, że jest proste rozwiązanie tego typu problemów - systemy kontroli wersji (angielskie nazwy - Version Control, Revision Control, Source Control).

Informacje ogólne

Kontrola wersji polega na zapisywaniu historii zmian jakie zaszły w poszczególnych plikach projektu. Dzięki temu dostajemy możliwość cofania zmian jeśli okazały się błędne. Jeżeli skasujemy jakieś pliki albo uszkodzimy projekt, możliwe jest jego odtworzenie.

Zmiany są zapisywane w blokach, dzięki czemu np. zmiana nazwy funkcji w pliku c i odpowiadającym mu pliku .h może być logicznie traktowana jako jedna zmiana.

Pakiety zmian są archiwizowane i przechowywane na serwerze (może być to także serwer lokalny), dlatego zmian może dokonywać kilka osób na raz. Możliwe jest również dzielenie projektu na gałęzie skupiające się na dodaniu konkretnych funkcjonalności czy usunięcie błędów. Następnie mogą być one dołączone z powrotem do gałęzi głównej tak, aby wynikowy kod zawierał funkcjonalności dodane w każdej z tych gałęzi.

Co więcej nawet najlepsze systemy tego typu są całkowicie darmowe. Ale sytuacja np. na uczelniach jest bardzo podobna jak w przypadku innych dobrych praktyk programistycznych. Po co o tym wspominać, niech się sami męczą, niech wyrabiają sobie złe nawyki i niech się potem dziwią, że w rzeczywistości podchodzi się do problemu zupełnie inaczej.

Rodzaje systemów kontroli wersji

System scentralizowany

Istnieją dwa typy systemów kontroli wersji. W systemie scentralizowanym (CVCS - Centralized Version Control System) programista ma na dysku aktualną wersję projektu, a cała historia przechowywana jest na centralnym serwerze. Pakiety zmian dodajemy bezpośrednio do centralnego repozytorium. Jeżeli chcemy pracować na innej wersji programu, odpowiednie pliki są ściągane z serwera i podmieniane.

Możemy również porównać aktualną wersję z którąś z poprzednich. Najważniejszymi przedstawicielami tego modelu kontroli wersji są CVS i Subversion (SVN). Jest on chętnie wykorzystywany przez duże korporacje prowadzące projekty przez wiele lat. Aby spełnić ich potrzeby tworzone są również płatne systemy takie jak IBM Rational ClearCase.

System rozproszony

Alternatywą są systemy rozproszone (DVCS - Distributed Version Control System). Zostały one stworzone głównie z myślą o projektach open source.

W DVCS użytkownik trzyma na dysku dokładną kopię repozytorium z centralnego serwera zawierającą nie tylko aktualną wersję, ale również całą historię. Takie podejście może wydawać się nieefektywne, ale system nie archiwizuje całych plików. Zamiast tego zapisuje same różnice pomiędzy poszczególnymi wersjami i na tej podstawie jest w stanie odtworzyć zawartość pliku. Dzięki takiemu podejściu użytkownik może dokonać wielu zmian na swoim lokalnym repozytorium i uploadować je na serwer centralny dopiero kiedy uzna to za stosowne. Najpopularniejsi przedstawiciele tej kategorii to Git i Mercurial (hg).

Operacje na lokalnie zapisanej historii wykonują się dużo szybciej. Poza tym jeśli utracimy połączenie z serwerem, możemy dalej pracować. Dodatkowo każdy klon repozytorium jest jednocześnie pełnym backupem. Z kolei systemy scentralizowane lepiej nadają się do pracy z dużymi plikami binarnymi, w których nawet mała zmiana logicznej zawartości może całkowicie zmieniać zawartość binarną.

Przygotowanie środowiska

W dalszej części artykułu będę się posługiwał Mercurialem, nakładką graficzną TortoiseHg i serwisem hostingowym Bitbucket. Dlaczego tak? Moim zdaniem do zastosowań indywidualnych systemy rozproszone są dużo lepsze.

Mercurial mimo, że mniej popularny od Gita, jest uznawany za prostszy do opanowania. Poza tym Git nie jest tak dobrze przystosowany do pracy pod Windowsem. Tortoise to oprogramowanie zapewniające nakładki graficzne na popularne systemy kontroli wersji w zależności od wybranego systemu, możemy użyć: TortoiseHg, TortoiseGit, TortoiseSvn.

Nie będę tutaj opisywać instalacji TortoiseHg i zakładania konta na Bitbucket. Myślę, że każdy powinien z tym sobie bez problemu poradzić. W razie czego można skorzystać z tutoriali Bitbucketa. Jest tam również opis wstępnej konfiguracji TortoiseHg.

Podstawowe operacje

Dodawanie plików

Aby utworzyć nowe repozytorium wybieramy odpowiednią lokalizację, a następnie w explorerze klikamy prawy przycisk w docelowym folderze i wybieramy opcję:

TortoiseHg->Create Repository Here.

Tworzenie repozytorium.

Tworzenie repozytorium.

Docelowy folder może być pusty. Wtedy robimy repozytorium od zera i musimy w nim utworzyć odpowiednie pliki lub skopiować je z innego miejsca. Możliwe jest też tworzenie repozytorium w folderze zawierającym już istniejący projekt. Właśnie taka sytuacja została tutaj przedstawiona.

Następnym krokiem jest dodanie plików do repozytorium. Możemy to zrobić klikając:

TortoiseHg->Add i wybierając odpowiednie pliki.

svn_2

Dodawanie plików do repozytorium

Możemy również wybrać opcję TortoiseHg->Commit i otworzy nam się nowe okno. Po lewej stronie będziemy mieli listę plików repozytorium i ich status. Należy tam zaznaczyć interesujące nas pliki i wybrać dla nich opcję Add.

Ignorowanie plików

W tym celu należy kliknąć prawym przyciskiem na plik i wybrać opcję ignore. Otworzy się wtedy dodatkowe okno, w którym dodajemy pliki do listy ignorowanych. Jeżeli klikniemy prawym na jeden z plików na liście w nowym oknie, będziemy mogli dodać do ignorowanych wszystkie pliki z danego folderu albo o konkretnym rozszerzeniu. Lista ignorowanych plików przechowywana jest w pliku .hgignore, który również warto dodać do śledzonych plików.

svn_3

.hgignore

Teraz możemy napisać wiadomość i dokonać commita. W ten sposób zmiany zostaną zapisane w repozytorium lokalnym.

Tworzenie nowych commitów i gałęzi

Następnie dodałem 4 następne commity. Utworzyłem w nich nowy plik time.c i dodałem do niego trochę kodu. Aby teraz cofnąć się do poprzedniej wersji należy w folderze projektu kliknąć prawy przycisk i wybrać HgWorkbench. Repozytorium otworzy się teraz w TortoiseHg. Wybieramy rewizję, do której chcemy się cofnąć, klikamy prawy przycisk myszy. Wybieramy opcję Update. Po wykonaniu tej operacji wszystkie późniejsze zmiany zostały cofnięte.

Przywracanie wybranej wersji.

Przywracanie wybranej wersji.

Następnie dodałem kilka kolejnych commitów ze zmianami w pliku time.c tworząc w ten sposób dwie gałęzie (branche).

Scalanie wersji

Aby dokonać ponownego scalenia jedną gałąź mam zaznaczoną jako aktualną, a drugą klikam prawym przyciskiem i wybieram opcję merge with local W kolejnym oknie należy potwierdzić merge. Jeżeli zmiany były dokonywane w innych miejscach, merge wykona się automatycznie.

svn_5

Scalanie wersji.

Czasem jednak ma miejsce konflikt. Należy wtedy wybrać opcję resolve i w kolejnym oknie dokonać merge za pomocą dodatkowego programu. Zaznaczony na rysunku program zewnętrzny kdiff3 jest instalowany razem z Tortoise. Po jego wybraniu i naciśnięciu przycisku Tool Resolve często wykona się automatyczny merge. Czasem jednak niezbędne będzie ręczne dokonanie zmian.

svn_6

Program kdiff3.

Po zakończeniu merge należy się upewnić, że projekt działa tak jak powinien i można dokonać commita. Jak widać na branche zostały z powrotem połączone.

svn_7

Gałęzie po połączeniu.

System kontroli wersji umożliwia również zmienianie nazw plików oraz ich usuwanie.

Edycja nazw plików

Aby zmienić nazwę pliku klikamy go prawym przyciskiem i wybieramy:

TortoiseHg->Rename File.

Zmiana nazwy pliku

Zmiana nazwy pliku

Usuwanie plików

Jeżeli chcemy usunąć plik, wybieramy TortoiseHg->Remove Files. Jeżeli usunęliśmy plik w niepoprawny sposób, przy następnym commicie po lewej stronie nazwa skasowanego pliku wyświetli się z wykrzyknikiem obok.

svn_9

Niepoprawne usunięcie pliku.

Oznacza to, że pliku nie można znaleźć, ale nie zostanie on uznany za usunięty. Dlatego jeśli później wrócimy do tej rewizji, plik może pojawić się z powrotem. Poprawne usunięcie pliku jest sygnalizowane symbolem R obok nazwy pliku.

svn_11

Poprawne usunięcie pliku.

Operacja zmiany nazwy składa się z usunięcia starego pliku i dodania nowego. Dodatkowo zapisywana jest informacja o zmianie nazwy, dzięki czemu można w późniejszym czasie śledzić zmiany w pliku z czasu kiedy miał starą nazwę.

Łączenie repozytorium z BitBucket

Aby połączyć lokalne repozytorium z bitbucketem, należy założyć nowe repozytorium przez stronę. Następnie repozytorium lokalnemu trzeba przypisać ścieżkę serwera, do którego ma wysyłać zmiany. W tym celu wchodzimy do HgWorkbench z otwartym repozytorium. Wybieramy tam File->Settings. Otworzą nam się opcje w dwóch zakładkach. Jedna zawiera ustawienia globalne, a druga lokalne dla aktualnego projektu. Wybieramy drugą zakładkę i tam klikamy przycisk Edit File. Wewnątrz pliku dopisujemy:

Gdzie url to adres do projektu bitbucket. Możemy go odczytać ze strony projektu po prawej stronie (zaczyna się od https i naszej nazwy użytkownika). Zapisujemy zmiany w opcjach HgWorkbench i wykonujemy operację "Push outgoing changes to selected URL". W ten sposób zmiany zostaną wysłane na serwer. Poniżej podgląd commitów w bitbuckecie.

svn_12

Repozytorium w BitBucket.

Dla lepszego zapoznania się z możliwościami TortoiseHg polecam przestudiowanie manuala.

Kilka porad

  • Kontrola wersji najlepiej się sprawdza dla plików tekstowych, w których łatwo zarządzać zmianami. Dotyczy to również różnego rodzaju plików konfiguracyjnych wczytywanych przez programy np. w formacie xml. Jednak w tym wypadku mogą wystąpić pewne problemy.
  • Warto objąć kontrolą wersji również inne przydatne pliki, których nie planujemy zmieniać. Mogą to być datasheety elementów, manuale, schematy elektryczne, schematy działania algorytmów czy przepływu komunikacji itp.
  • Kontrola wersji w projektach wykorzystujących pliki inne niż tekstowe nie jest efektywna. Różnice pomiędzy kolejnymi pakietami zmian są trudne do przechowywania dla systemu, nie da się również efektywnie mergeować różnych gałęzi. Dlatego zastosowanie kontroli wersji do projektów eagle, autocada czy nawet worda jest zdecydowanie bardziej ograniczone.
  • Kontrola powinna obejmować jedynie pliki które bezpośrednio zmieniamy, a pliki generowane automatycznie powinny być pomijane. Dlatego zwykle dodajemy do kontroli pliki źródłowe, biblioteki zewnętrzne, makefile, dodatkowe skrypty, dane testowe itp natomiast pliki powstające w wyniku kompilacji dodajemy do listy ignore.

Issue tracker

Serwisy takie jak Bitbucket oferują również kilka dodatkowych funkcjonalności, które można zintegrować z systemem kontroli wersji. Najważniejszą z nich jest issue tracker. Pozwala on na:

  • opis znalezionych problemów i zapisywanie historii ich rozwiązywania
  • przechowywanie w jednym miejscu kontekstu problemu: opis słowny, logi, linki, podjęte działania
  • sprawdzenie czy nowo wykryty problem ma związek z czymś wcześniejszym
  • integrację z kontrolą wersji - wskazanie w którym commicie problem się pojawił, a które służyły do jego usunięcia
  • zapamiętanie problemu do późniejszego rozwiązania jeśli aktualnie zajmujemy się czymś ważniejszym
  • zapisywanie propozycji rozszerzeń, zadań do wykonania, nowych modułów

Obsługa trackera jest bardzo prosta - otwieramy odpowiednią zakładkę na stronie projektu i wyświetla nam się lista. Na rysunku tracker dla projektu tortoisehg . Jeżeli wybierzemy któryś wpis, otwiera się widok szczegółowy. Możemy również dodawać nowe wpisy. Poza dodaniem tekstu i załączników można im nadawać także typ (np. bug, feature) czy priorytet.

Podsumowanie

W artykule postarałem się przybliżyć podstawowe informacje i wykorzystanie przyjaznych w użyciu narzędzi umożliwiających łatwe dodanie kontroli wersji do domowych projektów.

Temat kontroli wersji jest bardzo rozbudowany. Zachęcam do głębszego zapoznania się z nim, aby wypracować konfigurację optymalną dla siebie. W internecie łatwo znaleźć przydatne artykuły, tutoriale, blogi i inne pomocne materiały na ten temat.

Mercurial, programowanie, projekt, SVN, system kontroli wersji