czwartek, 19 sierpnia 2010

Mercurial FTW

Zabawę z Mercurialem rozpocząłem standardowo: ściągnąłem i zainstalowałem co uznałem za konieczne (samego MercurialaPython'aTortoiseHG oraz VisualHG). Potem przyszedł czas na podstawy obsługi, w tym celu przeczytałem (i cześć z tego wypróbowałem samodzielnie) wstęp do Mercuriala. I zachwyciłem się ideami, które leżą u podstaw wszystkich DVSC. 
Lokalne repozytorium daje wspaniałe możliwości. Można pracować samemu (w odłączeniu od reszty zespołu, bez dostępu do centralnego repozytorium) przez dłuższy czas i ciągle czerpać korzyści z kontroli wersji. Commity wykonuje się lokalnie, można je przeglądać, cofać się do poprzednich wersji, przywracać najnowsze i dopiero gdy wszystko wygląda OK, wysłać na serwer. A wszystko to z niesłychaną wręcz prostotą i szybkością, której nie zaznałem podczas pracy z SVNem. 
Instalacja Mercuriala daje możliwość postawienia lokalnego serwera za pomocą jednego polecenia:
hg serve
Dzięki niemu można w bardzo przejrzysty i wygodny sposób przeglądać lokalne repozytorium.
Na pochwałę zasługuje niesamowicie sprawna i transparentna współpraca wszystkich narzędzi: Mercuriala obsługiwanego z linii komend, TortoiseHG oraz VisualHG. Można korzystać naprzemiennie ze wszystkich tych narzędzi w zależności od preferencji i nie powoduje to żadnych konfliktów. TortoiseHG ładnie integruje się z eksploratorem i pozwala na wygodne przejrzenie wszystkich zmian przed wykonaniem commitów. 
Podoba mi się także zastosowany sposób rozwiązywanie konfliktów: najpierw należy pobrać zmienione repozytorium z serwera, wtedy istnieje możliwość podejrzenia zmian na spokojnie w swoim lokalnym repozytorium. Następnie należy rozwiązać konflikty, na przykład za pomocą KDiff3, wykonać nowy commit, który połączy obie wersje i wysłać go na serwer. 
Istnieje jeszcze cała masa możliwości, których nie wypróbowałem i kolejna mnogość opcji, o których nawet nie wiem, ale to co na razie  poznałem pozwala mi mieć nadzieję, że współpraca z Mercurialem ułoży mi się znakomicie. Już widzę dla niego całą masę zastosowań w nadchodzącym semestrze na uczelni, szczególnie przy pisaniu wieloosbowych sprawozdań.

Praca z Mercurialem
Po instalacji proponuję zacząć od ustawienia nazwy użytkownika. Bez tego nie można  nawet wykonywać commitów do lokalnego repozytorium, chociaż ponoć domyślnie ma być możliwość pracy jako default@localhost. W tym celu odnajdujemy plik mercurial.ini w katalogu domowym (w przypadku Win7 mam na myśli C:\Users\<nazwa_uzytkownika>) i dodajemy do niego coś takiego:
[ui]
username = Imię Nazwisko <login@example.com>
Nie będę się tu rozpisywał na temat komend wykonujących konkretne czynności, chcę tylko wspomnieć o kolejności działań podstawowych operacji:
  • pracy z lokalnym repozytorium
    1. stworzenie repozytorium przez hg init
    2. dodanie plików objętych kontrolą wersji przez hg add
    3. praca z plikami
    4. jeśli wszystko jest w porządku to hg commit -m "komentarz"
    5. jeśli nie jest to hg revert
    6. powrót do punktu 3.
  • aktualizacji plików na serwerze
    1. pobranie aktualnej wersji z serwera przez hg pull
    2. wykonanie połączenia z naszą wersją dzięki hg merge
    3. sprawdzenie czy wszystko działa jak należy
    4. wykonanie lokalnego commitu połączonej wersji
    5. przesłanie plików na serwer przez hg push
    Dodawanie plików nieobjętych kontrolą
    Gdy stworzyłem lokalne repozytorium mojego projektu, jeszcze przed przesłaniem na serwer zaobserwowałem niechciane zjawisko. Kontrolą wersji zostały objęte wszystkie pliki w podkatalogach projektu, w tym także katalogi bin i obj. Nie widzę najmniejszego sensu by były  one na bieżąco sprawdzane i kontrolowane.
    Aby temu zapobiec wystarczy stworzyć plik .hgignore (jest on tworzony przez TortoiseHG przy zakładaniu repozytorium) i w nim umieścić wpis:
    syntax: glob 
    
    bin/** 
    obj/**
    
    Dzięki temu, oba katalogi wraz ze wszystkim co zawierają zostaną pominięte przy dodawaniu nowych plików.
    Zastanawiam się ciągle czy nie wykluczyć spod kontroli wersji wszystkich plików *.csproj oraz *.sln, gdyż zmieniają one swoją zawartość, gdy zamykam VS lub dodaję coś do projektów. Tworzy to troszkę zamieszania, jednak na razie wydaje mi się, że mogą one być przydatne w przypadku wielkiej katastrofy.

    2 komentarze:

    1. "Zastanawiam się ciągle czy nie wykluczyć spod kontroli wersji wszystkich plików *.csproj oraz *.sln"
      Ściągnę źródła i będę "odtwarzał" pliki .csproj? Jak najbardziej powinny być wersjonowane. Przy większych projektach odtworzenie plików projektów to droga przez mękę.
      Artur

      OdpowiedzUsuń
    2. Masz rację. Po namyśle doszedłem do podobnego wniosku. Dlatego też pliki zostają pod kontrolą Mercuriala.

      OdpowiedzUsuń