Mercurial

Opis zdecentralizowanego system kontroli wersji Mercurial i podstaw korzystania z niego do zarządzania kodem

Mercurial wraz z Subversion czy CVS należy do grupy aplikacji określanych mianem systemów kontroli wersji. Umożliwiają one sprawną prace wielu programistów nad jednym projektem. W odróżnieniu do Subversion jest zdecentralizowanym systemem kontroli wersji, gdzie nie ma jednego głównego repozytorium (narzuconego przez implementację). Prace nad Mercurialem ruszyły w kwietniu 2005 roku, po tym jak programiści jądra Linuksa postanowili porzucić BitKeepera na rzecz innej aplikacji. Z Mercuriala korzysta openSolaris, XEN, OLPC, projekt ALSA, e2fsprogs i wiele innych. Aplikacji przyświecają dwa cele - prostota obsługi i wydajność.

Instalacja

Mercurial znajdziemy w repozytoriach pakietów większości dystrybucji, a jeżeli go brak to wystarczy pobrać źródła ze strony projektu. Mercurial napisany jest w Pythonie z niewielkim dodatkiem C. Instalowanie "ze źródeł" to wydanie polecenia:
python setup.py install

Słowniczek Mercuriala

  • repozytorium (repository) - katalog zawierający historię mojego projektu. Wszystkie czynności zachodzą w repozytorium, każdy użytkownik ma własne.
  • katalog roboczy (working directory) - kopia (snapshot) repozytorium o określonej wersji/rewizji. Zawartość można edytować, a zmiany zapisane zostaną gdy prześlę je do repozytorium (commit)
  • rewizja (changeset) - stan projektu w danym czasie. Określa autora rewizji, opis zmian, listę zmodyfikowanych plików
  • gałąź (branch) - dwie lub więcej rewizji posiadających tą samą rewizję-matkę. Normalnie repozytorium przedstawia kod bieżący. Gdy chcemy np. wydać kilka wersji naszego programu tworzymy gałęzie, np. "program1.0", "program2.0". Każda gałąź zachowuje niezależność (jeżeli programista tego chce) i umożliwia np. łatanie kodu programu w "wersji" 1.0 niezależnie od 2.0 czy kodu bieżącego (head). Gałęzie często są również tworzone w celu dodania/edycji dużych ilości kodu w aplikacji, co wiąże się z niedziałającą aplikacją do czasu dokonania wszystkich zmian. Stworzenie gałęzi powoduje że bieżący kod nie jest "niszczony" i inni programiści mogą pracować. Gdy duże zmiany są gotowe łączy się gałąź zawierającą te zmiany z główną gałęzią.

Zaczynamy przygodę

  • W pustym katalogu wykonujemy polecenie (jako zwykły user) hg init repozytorium (gdzie "repozytorium" określa nazwę repozytorium)
  • Stworzony zostanie katalog "repozytorium", do którego przechodzimy. Stwórz przykładowy plik tekstowy w tym katalogu
  • Wykonaj polecenie hg add plik.txt, gdzie "plik.txt" to nazwa pliku jaki stworzyłeś
  • Plik zostanie dodany do repozytorium i mercurial będzie go śledził
  • Polecenie hg status wyświetli stan repozytorium (nowe, zmienione pliki itp.). W naszym przypadku pojawi się coś takiego
A plik.txt
Plik "plik.txt" został dodany do repozytorium (A - added). By zapisać nasze czynności należy "wysłać" je do repozytorium ("komitować" - commit) za pomocą polecenia hg commit. Zostaniemy poproszeni o podanie krótkiego opisu zmian, po czym zostaną one zapisane. hg status nie wykaże teraz żadnych zmian w repozytorium w stosunku do ostatniej zapisanej wersji.
W przypadku pracy w zespole dojdzie szereg innych poleceń. W powyższym przypadku pracowaliśmy bezpośrednio na stworzonym repozytorium. W subversion musielibyśmy pobrać wersję roboczą, w niej wprowadzać zmiany i komitować do repozytorium. Mercurial jest zdecentralizowany i nie ma takiego centralnego repozytorium. Stworzone przez nas repozytorium jest zarazem kopią roboczą (katalog roboczy), do którego możemy importować/eksportować zmiany z innych kopii repozytorium.

By skopiować repozytorium wystarczy wydać polecenie hg clone /ścieżka/url/do/repozytorium nazwa_kopii, gdzie "nazwa_kopii" to nazwa katalogu w jakim kopia zostanie umieszczona. Otrzymamy równocenną kopię repozytorium. Gdy w kopii dokonamy zmian i je skomitujemy obowiązywać to będzie tylko dla tej kopii. By przesłać zmiany do oryginalnego repozytorium stosujemy hg push /ścieżka/url/do/repozytorium lub z oryginalnego repozytorium pobieramy zmiany z kopii: hg pull /ścieżka/url/do/repozytorium. Po pobraniu zmian twój katalog roboczy nadal będzie miał tą samą rewizję - nie zobaczysz pobranych zmian dopóki nie zaktualizujesz kopii poleceniem hg update. Więcej dokumentacji dostępne jest wraz z aplikacją jak i na stronie projektu.
blog comments powered by Disqus

Kategorie

Strony