Mercurial (Kommando hg) ist ein modernes und einfach zu handhabendes Versionskontrollsystem. Projekte wie Python, Xen oder MoinMoin verwenden es und es ist auch für Projekte der Größe des Kernels Linux zu verwenden - aus diesem Grund hat wohl auch das OpenSolaris Projekt Mercurial als VCS gewählt. (Übrigens gibt es eine nicht geringe Anzahl Linux-Kernel-Entwickler, die git nicht mögen, und auch Mercurial nutzen. Dieses Mercurial-Repository wird ständig mit dem git-Repository abgeglichen.)
Mercurial ist in Python geschrieben (mit 2 kleinen Modulen in C zur Geschwindigkeits-Optimierung) und hat sehr kompakten Code. Mercurial hat einen kleinen Web-Server mit eingebaut, den man benutzen kann, wenn man "auf die Schnelle" mal ein Repository veröffentlichen (oder einfach nur selbst mit dem Web-Browser drüberschauen will).
Mercurial arbeitet so schnell, dass man sich manchmal fragt, ob es wirklich alles richtig gemacht hat. 
Da es in Python implementiert ist, sollte es auf allen Plattformen mit Python-Support funktionieren, z.B. Linux, Mac OS X, Windows, ...
Homepage/Wiki: http://mercurial.selenic.com/ Buch: http://hgbook.red-bean.com/ (englisch)
Lizenz: GPL
Mini-Howto
Siehe: http://mercurial.selenic.com/wiki/GermanTutorial
Übersicht der wichtigsten Kommandos
hg clone - Repo klonen
Dient zur Anfertigung eines Repository-Klons. Es wird dabei eine lokale, vollständige 1:1-Kopie eines entfernten "Remote-Repositories" angelegt.
hg clone http://project.example.org/ project
Danach hat man ein neues Verzeichnis "project/", das (im Unterverzeichnis .hg) eine vollständige Kopie des Repos enthält. Ausserdem ist "project/" mit einer aktuellen Version aller Projektdateien befüllt.
Dieses Kommando wird nur selten gebraucht - nach Ausführung hat man ja eine Kopie des Repos.
hg log - Änderungshistorie anzeigen
Anzeigen der Änderungshistorie - wer hat wann was geändert:
hg log | more
I.d.R. will man die Ausgabe durch more (less) leiten, weil da sehr viel kommen kann.
hg diff - was für Inhalte habe ich geändert?
Man zeigt damit die Änderungen im Arbeitsverzeichnis gegenüber der Revision im Repo an, auf der diese Änderungen basieren (also von der man ausging, als man angefangen hat).
Dieses Kommando sollte sehr oft benutzt werden, damit man sich vor dem "commit" bewusst ist, was man eigentlich genau alles committed. Man vermeidet damit, dass man weitere commits zur Fehlerkorrektur oder Ergänzung machen muss. Erfahrene Benutzer achten peinlich genau darauf, dass ihre Commits "clean" (sauber) sind, das bedeutet, dass ein Commit nichts unbeabsichtigt ändert, dass er vollständig ist, dass er ein bestimmtes Thema umfasst, dass der Kommentar zu den Änderungen passt, usw.
hg diff | more
hg status - Status des Arbeitsverzeichnisses
Man sieht hiermit, welche Dateien geändert ("Modified"), welche hinzugefügt ("Added"), welche entfernt ("Removed") wurden, welche unbekannt ("?") und welche verschwunden ("!") sind.
Dieses Kommando sollte öfters verwendet werden, siehe Kommentar bei "hg diff".
hg status | more
hg commit - Änderungen verewigen
Hat man an einigen (bereits vorhandenen) Dateien änderungen vorgenommen und man ist fertig damit, will man diesen Satz von Änderungen verewigen, d.h. der Änderungshistorie hinzufügen ("committen").
Bevor man dies tut, sollte man sicher sein, dass man fertig ist und zufrieden mit den Änderungen. Dazu ist es sehr hilfreich, sich die Änderungen nochmal genau durchzuschauen und erst danach zu committen. Siehe dazu hg diff und hg status.
hg commit -m "hier eine genaue beschreibung, was man warum geaendert hat"
![/!\](/moin_static19/modernized/img/alert.png "/!\"){kind=small}
Bitte beachten: man sollte davon ausgehen, dass ein commit nicht mehr zurückzunehmen ist, er ist Teil der Historie und die Historie kann man nicht mehr ändern. Es gibt mit "hg rollback" eine Möglichkeit, dies doch zu tun, dies ist aber nur unter sehr begrenzten Randbedingungen machbar/anzuraten.
hg push
Vorausgesetzt man hat Schreibzugriff auf das andere Repo, kann man mit "push" (schieben) Changeset vom aktuellen Repo in das andere "Remote-Repo" übertragen. Das Standard-Remote-Repo, welches hg dafür verwendet steht in .hg/hgrc.
hg push
Bitte genau die Ausgaben dieses Kommandos lesen, sie können wichtige Hinweise enthalten.
hg pull
Man kann mit "pull" (ziehen) Changesets von einem "Remote-Repo" in das aktuelle Repo übertragen. Das Standard-Remote-Repo, welches hg dafür verwendet steht in .hg/hgrc.
hg pull -u
Die Option -u sorgt dafür, das danach auch das Arbeitsverzeichnis aktualisiert wird, was i.d.R. wünschenswert ist.
Bitte genau die Ausgaben dieses Kommandos lesen, sie können wichtige Hinweise enthalten.
hg merge
Es kann bei push/pull passieren, dass man eine Warnung bekommt bezüglich "multiple heads" und dass man "mergen" soll.
Das liegt daran, dass sich in beiden beteiligten Repositories die Historie seit dem letzten noch gemeinsamen Changeset unterschiedlich entwickelt hat:
- man hat lokal einige Änderungen committed
- jemand anderes hat im Remote-Repo andere Änderungen committed
In einem solchen Fall ist es notwendig, diese 2 divergierenden Entwicklungen wieder zu "mergen" (zusammenzuführen):
hg merge
Bitte genau die Ausgaben dieses Kommandos lesen, sie können wichtige Hinweise enthalten.
Im besten Fall waren die Unterschiede in verschiedenen Dateien bzw. in verschiedenen Stellen der gleichen Text-Datei, dann kann automatisch gemerged werden. Das Resultat dieses automatischen Merge-Vorgangs liegt dann im Arbeitsverzeichnis.
Im weniger günstigen Fall gibt es Konflikte, wenn 2 Personen an der gleichen Datei (bzw. an der gleichen Stelle innerhalb einer Text-Datei) geändert haben. Diese Konflikte muss man dann im Arbeitsverzeichnis sorgfältig manuell beseitigen.
Wenn es keine Konflikte gab bzw. nachdem man alle manuell bereinigt hat, muss man die Änderungen im Arbeitsverzeichnis dann noch committen:
hg commit -m "merged main repo"
Bitte in einem solchen "Merge-Commit" keine weiteren Änderungen machen, die nichts mit dem Merge zu tun haben.