Verteilte Versionsverwaltung

Ein Vergleich von Darcs, Git, Mercurial und Bazaar
von Jan Schütze

[zurück] ... [Übersicht] ... [vor]

Darcs

Darcs steht für Davids's Advanced Revision Control System. Es wurde von dem Physiker David Roundy im Jahr 2003 veröffentlicht. Darcs ist komplett in Haskell geschrieben und unter der GPL veröffentlicht. Im Gegensatz zu den meisten Versionsverwaltungssystemen verwaltet darcs nicht eine Folge von Revisionen sondern speichert Änderungen in einzelnen Patches. Diese können mit anderen Benutzern über HTTP, SSH, SFTP sowie per Email verbreitet werden. Aus einzelnen Patches können dann verschiedene Versionen eines Projektes erzeugt werden. Zum Erstellen verschiedener Entwicklungszweige wird einfach ein Klon eines vorhanden Repositorys erzeugt.

Verfügbarkeit

Für alle gängigen Betriebssysteme sind Versionen verfügbar, allerdings handelt es sich hierbei lediglich um Kommandozeilenprogramme. Grafische Oberflächen sind nicht verfügbar, es gibt jedoch Webinterfaces zum darstellen der Repositorys sowie ein Eclipseplugin.

Grundlegende Kommandos

Aktion Kommando
initialisieren darcs init
Checkout darcs get
Datei hinzufügen darcs add
Datei löschen darcs remove
Commit darcs record
Pull darcs pull
Push darcs push
Merge darcs pull/push
Clone/Branch erzeugen darcs get
Aktuelle Änderungen darcs whatsnew
Änderungsgeschichte darcs changes


Nach oben

Theory Of Patches

Ein Patch enthält eine oder mehrere Änderungen in dem aktuellen Entwicklungsbaum. Jeder Patch hat eine Repräsentation, die die Änderungen in dem Kontext eines speziellen Baumes beschreibt sowie eine Reihe von Regeln, die sein Verhalten beschreiben. Bei der übertragung in einen anderen Baum muss die Repräsentation an den jeweiligen Kontext des Baum angepasst werden. Der Kontext ist somit eine Menge von bereits angewendeten Patches.

Komposition
Die einfachste Verbindung zwischen Patches ist die Komposition, sie beschreibt eine einfache Aneinanderreihung von Patches:

Sequenz

Hierdurch wird ausgedrückt, dass zuerst Patch 1 und dann Patch 2 ausgeführt wird.


Parallelität
Zwei Patches sind parallel wenn sie dem selben Kontext entspringen:

parallel




Inverses Element
Die wichtigste Eigenschaft eines Patches ist, dass es ein inverses Element gibt:

inverses

Das inverse Element macht alle Änderungen des Patches wieder rückgängig. Daraus ergibt sich folgendes Theorem:
Das Inverse einer Komposition ist:

inverses2




Kommutation
Die Kommutation beschreibt das Vertauschen der Reihenfolge von zwei Patches:

kommutativ

Die linke und die rechte Seite führen insgesamt jeweils zum selben Ergebnis, jedoch werden einmal erst die Änderungen von Patch 1 und dann von Patch 2 und einmal die Änderungen von Patch 2 und dann von Patch 1 durchgeführt. In bestimmten Fällen kann kein Kommutativ erzeugt werden, dies ist immer dann der Fall wenn die Patches aufeinander aufbauen (Beispiel: Patch 1 erzeugt leere Datei X, Patch 2 fügt Inhalte hinzu).

bspkommutativ
Abbildung 3: Beispiel Kommutation


Im linken Ast wird erst mit Patch 1 "Bier" und anschließend mit Patch 2 "Kekse" hinzugefügt. Möchte man jetzt "Bier" wieder entfernen müsste man zuerst Patch 2 rückgängig machen, um dann auf Patch 1 zugreifen zu können. Durch das Kommutativ im rechten Ast ist es jetzt möglich direkt das inverse Element auszuführen, um "Bier" zu entfernen.


Merge
Merge beschreibt das zusammenfügen von parallelen Zweigen:

kommutativ

Das Ergebnis eines Merge von zwei parallelen Zweigen ist entweder Patch 1 sowie das Kommutativ des Zweiten oder Patch 2 sowie das Kommutativ des Ersten.

bspmerge
Abbildung 4: Beispiel Merge


Im linken Entwicklungszweig wird mit Patch 1 "Bier" hinzugefügt. Ein anderer Nutzer ändert mit Patch 2 den Namen der Liste in seinem Repository. Jetzt möchte der rechte Nutzer in seinem Repository beide Änderungen zusammenführen. Dazu braucht er ein kommutatives Element des Patches aus dem anderen Repository um daraus die komplette neue Liste zu generieren. Dieser Vorgang ist symetrisch.

Nach oben

[zurück] ... [Übersicht] ... [vor]