Mercurial: Die goldene Mitte

Der Umstieg zwischen Mercurial und Git gleicht in einem Punkt dem zwischen SVN und CVS: Bei allen grundlegenden Befehlen ersetzt der Anwender lediglich »git« durch »hg« . Zwar ist Mercurial überwiegend in Python und nicht in C programmiert, dennoch ähneln sich Repository-Struktur und funktionale Prinzipien stark. Viele Git-Plugins, zum Beispiel die für Netbeans und Trac (Tabelle 1) sind Forks des Mercurial-Plugin.

Auch Linus Torvalds nennt Mercurial in seinem Vortrag über Git [6] eine im Wesentlichen gleichwertige Lösung. Wegen seiner Python-Basis lässt sich Mercurial effizienter unter Windows nutzen, während Git dort auf die Cygwin-Umgebung [8] angewiesen ist und unter Performance-Einbußen leidet. Seit einiger Zeit gibt es allerdings auch eine native Windows-Version [9].

Im Lieferzustand besticht Mercurial durch einen handlichen, für die meisten Anwender völlig ausreichenden Feature-Umfang, der zudem systematisch und verständlich dokumentiert ist [10]. Gits sehr großer Leistungsumfang dagegen schreckt Einsteiger eher ab.

Ohne Erweiterungen gibt sich Mercurial bezüglich der History unbestechlich. Es ist – abgesehen von dem auch hier mit »rollback« revidierbaren letzten Commit – nicht möglich, ins Repository übertragene Dateien oder Changesets aus der Historie zu tilgen.

Transplantation

Mercurial enthält aber bereits im Lieferumfang Erweiterungen fürs Abändern der History, die man nur in der Konfigurationsdatei aktivieren muss. Mit der Transplant-Erweiterung [11] sind, wie der Name andeutet, Changesets zu verpflanzen. Der häufigste Anwendungsfall ist das von Git bekannte Rebasing, das die Changesets eines Branch in den Hauptzweig überträgt, als hätte der Entwickler sie direkt dort eingecheckt. Die Transplant-Extension unterstützt wie Git das Cherry Picking, also das Rauspicken von Revisionen (Abbildung 2).

Abbildung 2: Das partielle Mergen bestimmter Revisionen nennen Entwickler bildhaft Cherry Picking. Sowohl Git als auch Mercurial und Bazaar unterstützen dieses wählerische Herauspicken von Änderungen.

Der Preis für die in verteilten Revisionskontrollsystemen über Repository-Klone leicht erzeugbare mehrsträngige Revisions-History ist der Verzicht auf die fortlaufende Nummerierung der Versionen. Schließlich führen in einem verzweigten Baum Pfade mit unterschiedlicher Knotenzahl zum gleichen Commit. Git, Mercurial und Bazaar benutzen daher eindeutige Hashes, um Revisionen zu identifizieren.

Die unhandlichen Hashes darf der Anwender dabei abkürzen, solange sie eindeutig bleiben. Git bietet als Ersatz für durchlaufende Nummerierung die Notation »~3« , um in Befehlen auf die drittletzte Revision zu verweisen. Mercurial weist Check-ins zusätzlich zum eindeutigen Hash eine fortlaufende Nummer zu, die allerdings nur für ein bestimmtes Repository gilt und daher zu Missverständnissen führen kann.

Wie bei Git gibt es Mercurial-Plugins für die IDEs Eclipse und Netbeans, die jedoch etwas ausgereifter wirken als ihre Git-Pendants. Von der Windows-Software Tortoisehg [12] gibt es eine Linux-Variante, die sich in den Gnome-Dateimanager einklinkt (Abbildung 3). Wie Git bringt auch Mercurial ein einfaches Webfrontend mit, das immerhin einen Diff-Viewer mit Syntax Highlighting bietet. Auch Vi- und Emacs-Anhänger werden im Mercurial-Wiki fündig [13].

Abbildung 3: Tortoisehg, das sich in Namen und Aufbau an das bekannteste Windows-Frontend für SVN anlehnt, bietet unter Linux neben der Eclipse- und Netbeans-Anbindung die beste grafische Oberfläche für Mercurial.