Erste Erfahrungen mit Mercurial (Hg)

Wegen der Unabhängigkeit von einem zentralen Server, aber auch nicht zuletzt aufgrund zweier weiterer Dinge habe ich mich in den letzten Wochen mal etwas mehr mit Mercurial beschäftigt:

  1. dem Bundle-Befehl
  2. dem integrierten Webserver

Zwar hat Git ebenfalls einen Bundle-Befehl, aber der zweite Punkt gab dann vorläufig den Ausschlag.

Grundsätzliches zu Mercurial

Mercurial gehört in die Gruppe der „distributed source code management (DSCM) systems“ (Artikel in der deutschen Wikipedia). Das Wort „distributed“ (dt. „verteilt“) soll dabei die oben schon erwähnte Unabhängigkeit von einem zentralen System ausdrücken. Git, Mercurial und Bazaar sind vielleicht die bekanntesten, aber keineswegs die einzigen Vertreter aus dieser Kategorie. Mit irgend einem davon musste ich anfangen, und aus den oben genannten Gründen fiel meine Wahl auf Mercurial.

Generelle Vorgehensweise

Im Gegensatz zu zentral organisierten Systemen, die für fast alle Operationen eine Verbindung zum Server-Repository benötigen (mit den üblichen netzwerktechnischen Implikationen) holt man sich bei einem verteilten System zunächst einen „Klon“ des Repositories. Danach hat man lokal alle Informationen (auch die Historie) des Projektes verfügbar, so dass z.B. für die Abfrage des Logs oder dem Auschecken einer älteren Version keine Netzwerkverbindung benötigt wird. Dementsprechend gehen viele der täglichen Aktionen rasend schnell

Auch das Einchecken (engl. „committen“) oder Verzweigen („branchen“) ist möglich. Trotz der eventuell fehlenden Netzwerkverbindung braucht also niemand auf die Vorteile eines Versionsmanagements zu verzichten.

Sobald dann aber die lokale Arbeit einigermaßen vorzeigbar ist, kann natürlich auch mit einem entfernten Repository Kontakt aufgenommen werden. Sofern man dort Schreibrechte hat, kann man seine Änderungen direkt dorthin schicken. Falls nicht, können die beiden nachfolgend beschrieben Mechanismen zum Einsatz kommen.

Bundle

Neben den „normalen“ Möglichkeiten einer Quellcodeverwaltung, die im Falle der Produkte mit dem Zusatz „distributed“ eben auch völlig losgelöst von einem Server arbeiten können, erlaubt der Bundle-Befehl, eines oder mehrere Changesets zu „bündeln“ und in einer komprimierten Datei z.B. per eMail zu verschicken. Der Empfänger importiert die Changesets dann in sein lokales Repository und erhält im Ergebnis ein genaues Abbild mit allen Änderungen. Da Mercurial dabei dank der verwendeten Hash-Werte den Überblick über die Änderungen und deren Historie behält, können auf diese Weise auch Entwickler gemeinsam an einer Aufgabe arbeiten, die gar keinen schreibenden Zugriff auf das zentrale Repository haben.

Webserver

Der integrierte Webserver lässt sich normalerweise lokal über die Adresse http://localhost:8000/ im Browser ansprechen. Sofern der verwendete Rechner keine Blockademechanismen verwendet, kann dies in einem Netzwerk auch von anderen Rechnern aus geschehen. Dann ist statt „localhost“ natürlich die jeweils gültige lokale Netzwerkadresse (IP oder Name im Netz) wie z.B. http://juengling.entwicklungsabteilung.meinefirma:8000/ zu verwenden.

Dabei entscheidet der Mitarbeiter darüber, welches seiner lokalen Repositories er über diesen Webserver freigibt. Damit können die Kollegen dann nur lesenden Zugriff auf das Repository nehmen und sowohl im Browser die Changesets anschauen oder mittels Mercurial über diesen Webserver einen eigenen Klon des Repositories anlegen.

Weiterführendes

Einen guten Einstieg in die Thematik bietet Joel Spolsky auf Hg Init (englisch). Er beschreibt dort sehr anschaulich seine anfänglichen Probleme beim Umstieg von einem zentralen Versionsverwaltungssystem auf Mercurial, bevor er Verfahrensweisen und Vorteile erläutert. Ohne diesen Text und die hilfreiche Anleitung eines Kollegen wäre ich sicher nicht so schnell damit klar gekommen.

Wenn ich Ihnen dabei helfen soll, lassen Sie es mich wissen :-)

Ähnliche Artikel:

Schreibe einen Kommentar

Your email address will not be published.

zwei × 4 =