Zustandsforschung

Vor ein paar Monaten bin ich über das verteilte Source-Control-Management-Tool Mercurial gestoßen und habe angefangen mich damit zu beschäftigen. Mittlerweile setze ich es im privaten wie im professionellen Bereich ein und weil ich es so toll und praktisch finde, möchte es euch hier ein bisschen näher bringen.

Unterschied zum zentralisierten Modell

Der wichtigste Unterschied zwischen Mercurial und traditionellen Versionierungssystemen wie CVS oder SVN ist das verteilte Modell. Das bedeutet, es gibt nicht mehr nur ein zentrales Repository, sondern jeder Entwickler hat quasi eine Kopie des zentralen Repositories bei sich lokal liegen.

Der Entwickler checkt nun zunächst in sein lokales Repository ein und kann damit arbeiten wie z.B. mit einem SVN, über das er die alleinige Kontrolle hat. Zu einem Zeitpunkt, an dem der Entwickler mit seiner Arbeit so weit zufrieden ist, dass er sie den anderen an dem Projekt beteiligten Entwicklern zur Verfügung stellen möchte, schiebt er alles in das übergeordnete Repository.

Bei diesem Vorgang wird nicht nur der aktuelle Stand hochgeschoben, sondern auch alle Zwischenstände, die der Entwickler an seinem lokalen Repository eingecheckt hat. Außerdem kann sich das übergeordnete Repository selbst von einem weiteren Repository bedienen, so dass nicht nur zwei Ebenen sondern eine ganze Repository-Hierarchie möglich ist.

Für mich selbst war zunächst vor allem die Tatsache ungewohnt, dass man bei sich lokal eincheckt – das klingt ein bisschen so als wäre der Code in größerer Gefahr, weil er ja nur auf dem eigenen Rechner liegt. In der Praxis erweist sich das aber als großer Vorteil, denn man kann auf die Art viel freier ausprobieren und auch mal Zwischenstände einchecken, die nicht so hundertprozentig stabil sind und die man normalerweise seinen Kollegen nicht als Checkin zumuten würde.

Mercurial

Mercurial selbst ist Open-Source-Software und benötigt Python ab Version 2.4 zum Funktionieren. Mitte 2005 gab Mat Mackall bekann, daran zu arbeiten. Mittlerweile hat Mercurial die Versionsnumer 1.6 erreicht und ist recht verbreitet – so werden unter anderem die Sourcen von FireFox, OpenOffice und Python damit verwaltet. Außerdem kann man bei den bei Google Code gehosteten Projekten außer SVN auch Mercurial einsetzen.

Es gibt ein gutes Eclipse-Plugin, das sich MercurialEclipse nennt und eine Shell-Extension für Windows ähnlich dem bekannten TortoiseSVN, die sich TortoiseHG nennt.

Das folgende Mini-Tutorial zeigt allerdings den Standardfall: Mercurial über die Kommandozeile.

Mini-Tutorial

Der Befehl, um Mercurial aufzurufen ist hg (das chemische Zeichen für Quecksilber, englisch eben “mercurial” – soll wohl so ‘ne Art Wortspiel sein). Mercurial bring eine gute Dokumentation gleich mit. Eine Kurzversion wird angezeigt, wenn man nur hg aufruft – eine ausführlichere Variante wird bei hg help angezeigt.

Um ein neues Repository anzulegen, muss man nur in das Verzeichnis seiner Wahl wechseln (wo evtl. bereits nicht-versionierte Dateien liegen) und den Befehl hg init ausführen. Damit erstellt Mercurial ein neues Verzeichnis .hg, in das das komplette Repository abgelegt wird.

Nun kann man mit hg add und einem anschließenden hg commit -m "Adding files." seine Dateien in das Repository einchecken. Nun kann man den Source-Code weiterbearbeiten, irgendwann dann mit einem hg status nachschauen, was man so alles geändert hat und dann wieder mit hg commit einchecken.

Interessant wird es dann, wenn mehrere Repositories ins Spiel kommen. Möchte man jetzt eine Kopie des Repositories erstellen, wechselt man beispielsweise ins übergeordnete Verzeichnis und führt hg clone Original-Verzeichnis Clone-Verzeichnis aus. Dann kann man im Clone-Verzeichnis weiterarbeiten und auch hier einchecken.

Das Original-Verzeichnis ist so lange davon nicht betroffen, wie man ein hg push ausführt, das dann die Änderungen ins Original-Verzeichnis hochschieben würde. Idealerweise macht man vorher erst ein hg pull, um das Clone-Repository auf den neuesten Stand zu bringen und dann ein hg update, um die Dateien im Clone-Verzeichnis zu aktualisieren. Falls es im übergeordneten Repository schon Änderungen gegeben hat, muss vor dem Push mit hg merge gemergt werden.

Weitere Detail zur Nutzung von Mercurial kann man dem sehr guten Tutorial auf der offiziellen Mercurial-Seite entnehmen oder dem Tutorial von Joel Spolsky auf hginit.com.

Mercurial zusammen mit SVN

Man kann mit Mercurial auch dann nutzbringend einsetzen, wenn für das aktuelle Projekt ein anderes SCM wie zum Beispiel Subversion im Einsatz ist. Das kann dann folgendermaßen funktionieren:

Zunächst checkt man den Code wie gewohnt aus dem Subversion-Repository aus. Dann führt man im obersten Verzeichnis hg init aus. Dann legt man dort ein zusätzliches File .hgignore mit folgendem Inhalt an:

syntax: glob
.svn

Das verhindert, dass man die SVN-spezifischen Files mit eincheckt. Umgekehrt sollte man das Einchecken des .hg-Ordners ins SVN verhindern, indem man das svn:ignore-Property entsprechend setzt. Danach kann man mit hg add und hg commit das lokale Mercurial-Repository mit Inhalt füllen.

Nun arbeitet man immer zunächst gegen das Mercurial-Repository und checkt dort ein. Wenn man seinen Code der Allgemeinheit zur Verfügung stellen möchte, macht man schließlich ein svn commit. Man muss allerdings darauf achten, wenn man ein Update aus dem SVN macht, dieses Update auch in das lokale Mercurial-Repository einzuchecken.

Ein Wort zu git

Wenn es um verteilte Versionskontrollsysteme geht, fällt einem meistens vermutlich git ein. Wahrscheinlich hat man schon davon gehört, wie toll git ist und was git alles kann. Es gibt sogar eine Internetseite, die erklärt warum git besser ist als alles andere. Warum also Mercurial ausprobieren?

Für meine Begriffe liegt die Popularität von git – abgesehen davon, dass es sicher ein geniales SCM ist – hauptsächlich daran, dass die git-Benutzer lauter schreien als die Mercurial-Benutzer Ich bin immer davon abgeschreckt, wenn irgendetwas zu sehr gehypt und zu vollmundig angepriesen wird. Deshalb habe ich mich dazu entschieden, Mercurial auszuprobieren. Mercurial-Benutzer müssen nicht rumlaufen und Leute missionieren – sie benutzen einfach ihr SCM und sind glücklich damit dass es so toll funktioniert.

Nein. Scherz. Ich denke die Entscheidung sollte im ersten Schritt nicht zwischen Mercurial oder git getroffen werden, sondern für ein verteiltes Versionskontrollsystem. Denn das ist das zentrale Merkmal, das beide Systeme auszeichnet. Der Rest ist dann Geschmackssache.