Monotone und Arch

Versionskontrolle unter Linux bedeutet für die meisten Programmierer CVS. Dass dieses System auch einige Schwächen hat, ist allgemein bekannt. So kennt CVS weder einfaches Umbenennen noch Atomic Commits (siehe Kasten "Begriffe"). Es gibt verschiedene Alternativen, die diese Probleme lösen wollen, siehe[1].

Versionskontrollsysteme (Version Control Systems, kurz VCS, oder Source Control Management, kurz SCM) lassen sich anhand der Art, wie sie ihre Daten speichern und verwalten, in zwei Grundkategorien einteilen:

• Zentrale Datenhaltung und Administration
• Dezentrale, verteilte Speicherung und Organisation

Abbildung 1 zeigt den Unterschied zwischen den beiden Ansätzen. Das zentrale Modell dient vor allem dazu, den Wildwuchs an unterschiedlichen Programmvarianten zu verhindern. Jede bleibende Änderung findet ihren Niederschlag im Repository. Bevor Programmierer ihre Modifikationen in das Repository überführen, müssen sie sich erst die aktuelle Version herunterladen und entstandene Konflikte lösen. Der zentrale Server vergibt Versionsnummern und macht damit eine fortlaufende Nummerierung möglich (1.1 wird zu 1.2). Subversion[2] gehört zur ersten Art und war Thema im Linux-Magazin 06/03. Im Folgenden geht es um zwei freie Programme der dezentralen Variante: Gnu Arch[3] und Monotone[4].

Verteiltes gegen zentrales Entwickeln

Beim zentralen VCS ist der Server ein Single Point of Failure: Fällt er aus, kann kein Entwickler Daten aktualisieren oder verändern. Mit anderen unter VCS-Kontrolle Code austauschen ist dann nicht möglich. Wer ohne Zugriff aufs Dateisystem einen CVS-Server repliziert, verliert meist alle Änderungsinformationen. Die bleiben nur beim direkten Kopieren auf Dateisystemebene erhalten.

Die dezentralen oder auch verteilten Versionsverwaltungssysteme (Distributed Version Control Systems, kurz DVCS) erlauben mehrere (fast) identische Server. Jeder von ihnen führt sämtliche Informationen über Änderungen am Programmcode.

Jede Datei muss zu allen Zeiten eine eindeutige Versionsnummer besitzen. Ohne eine zentrale Vergabe der Nummern gibt es dafür zwei Ansätze: entweder über so genannte Hashes (zum Beispiel SHA1 oder MD5) oder mit Hilfe einer eindeutigen Namenskonvention.

In verteilten Versionsverwaltungssystemen tauschen die Benutzer ihre Daten direkt miteinander aus. Wenn die Arbeit untereinander abgeschlossen ist, transferiert ein Entwickler das gesammelte Ergebnis ins Hauptverzeichnis. Arbeitet ein anderer in der Zwischenzeit an einer älteren Version, müssen die Teile eventuell von Hand zusammengeführt werden. Dieser Fall ist jedoch äußerst selten, denn die meisten Systeme kennen dafür komplexe Algorithmen. Ein Beispiel ist das dreifache Zusammenfügen (Three Way Merge) in Monotone, das die meisten Konflikte selber löst.

Kandidat Nummer eins: Gnu Arch

Das Hauptprogramm von Gnu Arch[2] heißt »tla« (Tom Lord\'s Arch). Um Arch selbst zu kompilieren, ist das Quelltextpaket von[5] nötig, das nur von wenigen anderen Paketen abhängt[6]. Nach dem Entpacken des Quelltextpakets mit »tar xfz tla-Version.tar.gz« übersetzen die Standardschritte »./configure && make && make install« die Software. Per Default installiert das Skript das Programm nicht wie sonst üblich nach »/usr/ local«, sondern in ein Unterverzeichnis des Übersetzungsverzeichnisses. Abhilfe schafft »./configure --prefix= /Zielpfad«. So setzt man das Präfix gleich »/usr/packages/tla-Version«, um das Paket einfach entfernen zu können: »rm -rf /usr/ packages/tla-Version«.

Abbildung 1: Zentrale und dezentrale Sourcecode-Kontrolle.

In diesem Fall ist es nötig, den Suchpfad mit »export PATH=:/usr/packages/tla-Version« anzupassen oder das »link_script« von[7] unter Angabe des Präfix einzusetzen. Einige aktuelle Distributionen bringen Arch mit, zum Beispiel Debian Sid (»apt-get install tla«), Gentoo oder Suse 9.1 (über Yast).

Hinter dem Kommando »tla« folgt ein Befehl, der angibt, was das Programm machen soll - ähnlich wie bei CVS. Alle verfügbaren Befehle zeigt »tla help«, eine Übersicht der weiteren Parameter und eine kurze Erklärung gibt »tla Kommando -H« .

Bei Arbeitsbeginn teilt der Entwickler dem Arch-System seine Identität mit, zum Beispiel »tla my-id "Nico Schottelius <my-tla@mx0.info>"«. Solche Parameter speichert das Programm in der Datei »~/.arch-params«. In der sollte auch suchen, wer »tla«-Fehlermeldungen erhält.