Hg Clone: Ohne Netz, aber mit doppeltem Boden

Da in Mercurial nicht nur das Arbeitsverzeichnis, sondern auch das komplette Repository lokal vorliegen, ist der Begriff „Clone“ sicher gut gewählt und verständlich. Denn schon beim ersten Kontakt mit einem irgendwo gehosteten Mercurial-Projekt spricht man davon, dass man das entfernte Repository „klont“, also auf seinen lokalen Rechner kopiert. Mercurial kann das mit seinem Kommandozeilenbefehl hg clone tun. Alternativ bietet auch TortoiseHg einen gleichnamigen Befehl an, der in diesem Dialog die erforderlichen Daten entgegen nimmt:

Hg: Clone mit TortoiseHg

Nach der Ausführung hat man lokal eine vollständige Kopie des entfernten Repositories vorliegen, weshalb dann auch keine Netzwerkverbindung mehr erforderlich ist, um einfach nur zu arbeiten.

Vorteile des Klonens

Soweit das Cloning also eine technische Notwendigkeit ist, ist das noch nicht gerade spektakulär. Das Vorhandensein einer lokalen Kopie des Repositories ermöglicht es jedoch, ohne Netzwerk einige interessante Dinge zu tun:

  • committen (neue Changesets anlegen)
  • eine versehentlich veränderte Datei wieder herstellen
  • die Historie durchsuchen
  • auf einen älteren Stand der Historie updaten
  • einen Entwicklungszweig beginnen (Bugfix oder neues Feature)
  • erst wenn ich mit meiner Arbeit fertig bin, schiebe ich die Ergebnisse (Changesets) zurück auf das entfernte Repository („push“)
  • u.v.m.

Alles dies erfordert in einem zentralen Quellcodeverwaltungssystem einen Zugriff auf den Server. Ein Mercurial-Benutzer hingegen kann problemlos einige Zeit auch ohne Serververbindung arbeiten, z.B. im Zug oder im Hotel.

Seiteneffekte

Die Überlegung ist naheliegend: Wenn man so einfach einen Clone aus einem entfernten Repository erzeugen kann, wieso dann nicht auch ebenso einfach einen weiteren Clone aus einem lokalen Repository? Und in der Tat, das geht ebenso einfach (indem man als „Source“ das Basisverzeichnis des 1. Clones angibt), und es bringt ebenfalls die oben beschriebenen Vorteile mit sich. Ein weiterer Aspekt ist aber noch viel wichtiger:

  • Auf einem zweiten Clone kann ich Dinge ausprobieren, die ich erst dann in den ersten Clone übertrage („push“), wenn sie sich als sinnvoll herausgestellt haben.
  • War der Versuch allerdings eine Sackgasse, lösche ich einfach den zusätzlichen Clone und habe meine Entwicklungslinie nicht durcheinander gebracht.

Auf diese Weise kann ich einen Entwicklungszweig beginnen, und nachdem ich ihn zurückge“pusht“ habe, sieht es so aus, also ob ich gleich auf dem normalen Clone gearbeitet habe. Und das bringt eine Menge Stabilität und Sicherheit in meine Arbeit.

Verhältnis von Server zu lokalen Clones

 

[btcpayments address=“1HNv7eipZt9LHmmJnZT7VYjqdnUq7dmeKX“]


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

sechs + neun =