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"

/!\ 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:

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.


KategorieVersionsKontrollSystem

hg (zuletzt geändert am 2011-04-15 14:24:39 durch ThomasWaldmann)