Über den Status quo verteilter Versionsverwaltungssysteme
Seite 4: Vorteile verteilter Versionsverwaltung
Ein bedeutender Vorteil der verteilten Versionsverwaltungssysteme ist das einfache Branchen und vor allem das Mergen der Änderungen zurück in den Hauptentwicklungszweig. Ein Branch wird angelegt mit dem Befehl hg branch:
$ hg branch proj1-branch1
Arbeitsverzeichnis wurde als Zweig proj1-branch1 markiert
Nimmt ein Entwickler nun Änderungen vor und legt diese vor, erfolgt das in dem Branch proj1-branch1:
$ hg log
Änderung: 3:913d42a61e38
Zweig: proj1-branch1
Marke: tip
Nutzer: hcguersoy <guersoy@lendinarax>
Datum: Fri Mar 11 11:21:11 2011 +0100
Zusammenfassung: Änderungen im Branch vorgenommen#
Sollen die Änderungen in den Hauptzweig integriert werden, geschieht das mit hg merge aus dem Hauptzweig heraus.
$ hg update default
1 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst
$ hg merge proj1-branch1
1 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst
(Zusammenführen von Zweigen, vergiss nicht 'hg commit' auszuführen)
Mercurial erkennt bei einem Update, ob ein Konflikt vorliegt. Konflikt bedeutet hier, dass gleiche Bereiche einer Datei parallel verändert wurden. Falls ein Merge-Tool, wie im Beispiel, in der Mercurial-Konfiguration hinterlegt wurde, öffnet Mercurial die lokale Datei und deren Remote-Version in diesem, und der Benutzer kann den Konflikt beheben.
Das erfolgt alles noch lokal, und es findet noch keine Berührung mit einer anderen Kopie des Repository statt. Eine Kopie oder, um in der Lingua Mercurial zu bleiben, ein Klon lässt sich mit einem Befehl erzeugen. Änderungen, die in dem Klon stattfinden, sind erst einmal unabhängig von den Änderungen, die in dem ursprünglichen Repository stattfinden. Wie erwähnt, erfolgt eine Synchronisation der Änderungen zwischen Repositories mit Push und Pull. Das sei etwas näher betrachtet. Hierzu ist ein lokaler Klon anzulegen:
$ hg clone project1 proj1-clon1
Aktualisiere auf Zweig default
1 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0 Dateien ungelöst
Nach einem Wechsel in die Arbeitskopie des Klons, proj1-clon1, lassen sich nun Änderungen unabhängig von dem ursprünglichen Repository ausführen. Der Klon ließe sich aber auch auf einem anderen File-System legen und von einem anderen Benutzer bearbeiten.
Mercurial-Repository zum Artikel
Damit der Leser sofort loslegen kann, hat der Autor bei Bitbucket ein Mercurial-Repository mit dem Namen "HalloMercurial" für Testzwecke eingerichtet. Ein Klonen des Repositorys erfolgt mit dem Befehl
hg clone https://bitbucket.org/hcguersoy/hallomercurial
Falls der Leser ssh bevorzugt, geschieht das Klonen via
hg clone ssh://hg@bitbucket.org/hcguersoy/hallomercurial
Das Pullen und Pushen von Änderungen passiert wie im Artikel beschrieben mit hg pull und hg push. Die rege Teilnahme ist natürlich erwünscht.
Um kurzfristig Zugriff auf das lokale Repository zu gewährleisten, steht der Befehl hg serve zur Verfügung, mit dem man einen lokalen Webserver startet, wodurch ein anderer Benutzer einen Klon abrufen kann. Der Webserver ist in den Default-Einstellungen unter der Portnummer 8000 zu erreichen, zum Beispiel sollte http://localhost:8000 den Zugriff auf das lokale Repository ermöglichen. Push ist im Übrigen per Default bei einem auf die Weise gestarteten Webserver ausgeschaltet, da keine Zugriffskontrolle möglich ist. Daher wäre für längerfristiges Bereitstellen eines Repository-Servers ein "richtiger" Webserver zu verwenden. Ausführliche Anleitungen hierzu finden sich in der Mercurial-Dokumentation.
Angenommen, ein Anwender hat Änderungen in dem Klon vorgenommen, lassen sich diese nun mit einem Pull abrufen (zuvor hat er mit hg serve in dem Klon den Webserver gestartet):
$ hg pull http://localhost:8000
Hole von http://localhost:8000
Suche nach Änderungen
Füge Änderungssätze hinzu
Füge Manifeste hinzu
Füge Dateiänderungen hinzu
Fügte 1 Änderungssätze mit 1 Änderungen an 1 Dateien hinzu (+1 Köpfe)
("hg heads" zeigt alle Köpfe, nutze "hg merge" um sie zusammenzuführen)
Die Änderungen sind allerdings noch nicht sichtbar, erst mit dem Befehl hg merge nimmt man sie in die aktuelle Arbeitskopie auf und bestätigt sie abschließend mit einem Commit. Dadurch ist ein Benutzer auch nach einer Synchronisation frei in seiner Entscheidung, ob Änderungen in die lokale Arbeitskopie einfließen oder auch nicht.
Das war ein kleiner Ausschnitt der Möglichkeiten, die Mercurial bietet, wobei vieles analog für Git gilt. Viele weitere Kernfunktionen erleichtern das Leben als Entwickler, insbesondere im Zusammenspiel mit dem Branchen und Mergen. Hat er beispielsweise vergessen, mit dem Befehl copy oder move eine Datei im Kontext von Mercurial zu kopieren oder zu verschieben, lässt sich das mit hg addremove -similarity 100 nachholen (wobei die 100 für eine hundertprozentige Übereinstimmung steht). Dadurch geht nicht, wie bei Subversion, die Historie einer Datei verloren.
