Mit Versionskontrollsystemen behält man den Überblick über Änderungen an Textdateien. Besonders hilfreich sind sie bei der Teamarbeit von Programmierern.

Wer immer wieder die gleichen Dateien bearbeitet, wünscht sich häufig, noch Zugriff auf ältere Versionen zu haben. Viele Anwender lösen das mit Kopien der Dateien mit der Endung .bak oder einer Datumsangabe im File-Namen. Besser und übersichtlicher lässt sich die Geschichte einer Datei mittels Versionskontrolle konservieren.

Systeme zur Versionskontrolle (Englisch: Version Control System, VCS) speichern Dateien, die der Benutzer unter ihre Herrschaft stellt, in eigenen Verzeichnissen. Will er eine Datei bearbeiten, muss er sie zuerst mit einem speziellen Befehl aus diesem Speicher (Repository) holen, in der Fachsprache auschecken genannt. Ist er mit dem Editieren fertig, checkt er die Datei wieder ein. Das Versionskontrollsystem fordert ihn dann dazu auf, seine Änderungen zu kommentieren. Diese Kommmentare führt das VCS im so genannten Changelog.

Geregelte Gruppenarbeit

Versionskontrollsysteme werden vor allem von Programmierern verwendet, die den Source-Code von Software darin pflegen. Es spricht aber auch nichts dagegen, andere Dateien mit VCS zu verwalten. Viele Open-Source-Projekte bewahren zum Beispiel auch ihre Dokumentation in ihrem VCS auf.

Arbeitet nur eine Person an den Dateien eines Projekts, genügt schon eine einfache Lösung wie RCS (siehe Artikel in diesem Schwerpunkt). Freie Software-Projekte mit über die Welt verteilten Programmierern verwenden netzwerk- und multiuser-fähige Versionskontrollsysteme wie CVS oder Subversion.

Dabei liegt der Quellcode auf einem zentralen Server, und die Programmierer checken Verzeichnisse oder einzelne Dateien zur Bearbeitung aus. Der so genannte Commit schließt die Sitzung ab und legt die bearbeiteten Dateien wieder auf dem Server ab. Zu Konflikten kann es bei diesem Modell dann kommen, wenn zwei Programmierer gleichzeitig Änderungen an der selben Datei vornehmen. Diesen Fall fängt ein Versionskontrollsystem ab und bietet dem späteren der beiden Programmierer an, von Hand im Quellcode den Konflikt zu lösen. Das Update-Kommando aktualisiert die lokal gespeicherten Dateien auf den Stand des Repository.

Der Klassiker

Lange Zeit gab es im Linux-Umfeld nur ein Versionskontrollsystem: das Concurrent Version System CVS ([1], [2]). Weil es für jede Distribution als Paket zur Verfügung steht, erübrigen sich weitere Hinweise zur Installation. Alle beschriebenen Funktionen laufen über das Kommandozeilenprogramm cvs – natürlich gibt es aber auch grafische Frontends für CVS (Abbildung 1), zum Teil auch bereits in grafische Entwicklungsumgebungen integriert.

Abbildung 1: Das CVS-Frontend Cervisia zeigt grafisch den Verlauf der Versionen.

Hinter dem Befehlsnamen folgt die auszuführende Aktion, ausgeschrieben oder als Kürzel. So holt die Kombination cvs checkout respektive cvs co Dateien aus einem Respository. Dahinter steht die Ortsangabe des Servers, allerdings in einer etwas gewöhnungsbedürftigen Schreibweise: zuerst das Schlüsselwort pserver, von Doppelpunkten eingeschlossen, dann der Benutzername, gefolgt von einem @-Zeichen, dem Hostnamen und schließlich einem Pfad. Beim Gnome-CVS-Server sieht das so aus: :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome.

Um das nicht bei jedem Aufruf tippen zu müssen, versteht CVS die Umgebungsvariable CVSROOT, die diesen Wust aufnimmt. Steht darin, wie oben beschrieben, die Serverinformation, meldet sich der Benutzer mit cvs login an. Der Server fragt dann normalerweise nach einem Passwort. Vielen Open-Source-Projekten gestatten mit einem anonymen Login nur den lesenden Zugriff. Deshalb steht auch beim Gnome-CVS der Benutzername anonymous. Meist genügt es, bei der Passwortabfrage die Eingabe-Taste zu drücken. Verlangt der Server tatsächlich ein Passwort, geben die Webseiten eines Projekts meist mehr Hinweise dazu.

Bandbreite sparen

Nach dem Einloggen kopiert wie beschrieben der Befehl cvs co Verzeichnis die Dateien auf die lokale Festplatte. Zum Beispiel checkt check cvs co nautilus den Quellcode des Gnome-Programms Nautilus aus. Um Bandbreite zu sparen bietet CVS die Option -z, welche die Dateien bei der Übertragung komprimiert. Die höchste Kompressionrate empfiehlt sich nicht unbedingt, denn mehr Kompression belastet den Prozessor von Client und Server. Ein gebräuchlicher Wert ist -z3.

Wie schon erwähnt heißt das Einchecken der fertig bearbeiteten Dateien im VCS-Jargon auch Commit. Entsprechend lautet die CVS-Aktion dafür commit. Führt der Entwickler cvs commit aus, überprüft CVS selbst, welche Dateien er verändert hat. Es öffnet einen Editor, in dem der Programmierer für jede Datei seine Änderungen kommentiert. Schließt er den Editor, lädt CVS die Dateien mit dem Changelog ins Repository.

Die Entwicklung kann sich – wie beispielsweise bei Gnome – verzweigen: An den gleichen Dateien wird einmal weiterentwickelt, in einem anderen Zweig aber bleiben sie im Wesentlichen unverändert und die Entwickler plegen nur noch Bugfixes ein. Solche Zweige bildet CVS in so genannte Branches ab. Wer aus dem Gnome-Repository den stabilen Branch 2.0 auschecken will, muss den Branch-Schalter zusammen mit dem Branch-Namen verwenden: cvs co -r gnome-2.0.

Neben den drei wichtigsten CVS-Kommandos checkout, commit und update gibt es noch eine Vielzahl von weiteren Optionen und CVS-Konzepten. Über diese finden sich im Web eine Menge Informationen, etwa im CVS-Wiki von Ximbiot[3].

Der alte Neuling

Obwohl eine Unzahl an Projekten erfolgreich mit CVS verwaltet wurde, zeigten sich viele Programmierer unzufrieden mit dem System. So gab es Schwierigkeiten mit dem Umbenennen von Dateien, und es fehlt die Versionierung von Verzeichnissen.

So entschloss sich eine Gruppe von Programmieren um Karl Fogel, zwar nicht die Versionskontrolle neu zu erfinden, aber CVS ohne die vorhandenen Schwächen neu zu entwickeln. Daraus entstand Subversion, das sich im Open-Source-Bereich schnell verbreitet hat. Die Repositories sind nicht kompatibel, da Subversion ganz andere Metadaten führen muss als CVS. Für den Anwender erscheint die Bedienung aber im Wesentlichen identisch.

Das Kommandozeilenprogramm heißt zwar svn, aber es versteht wie CVS die Befehle checkout, update und commit. Weil Subversion mehr Netzwerkprotokolle als CVS beherrscht, sieht die Server-Information etwas anders aus. Ähnlich wie im WWW steht vor dem Hostnamen noch ein Service-Typ, zum Beispiel http für das HTTP-Protokoll, https für das gleiche mit SSL-Verschlüsselung oder svn für Subversions eigenes Protokoll. Letzteres gibt es auch noch in einer SSH-Variante.

Wer bei einem existierenden Projekt mitmachen will, muss sich keine Gedanken um die Wahl des Versionskontrollsystems machen. Ihm genügen für den Anfang die hier vorgestellten Befehle. Um für ein eigenes Software-Projekt ein VCS auszuwählen, empfiehlt es sich vor allem, auch auf dessen Popularität zu achten. Trotz seines Alters und einiger Schwächen genießt CVS noch immer eine hohe Verbreitung. Viele Open-Source-Projekte haben aber bereits auf Subversion umgestellt, und es werden immer mehr.

Verteilung und mehr

Neben den hier beschriebenen Versionskontrollsystemen mit zentralem Aufbau erfreuen sich in letzter Zeit so genannte verteilte VCS einer hohen Beliebtheit. Bekannt ist neben Arch/Monotone vor allem das neue Kernel-Versionsmanagement-System Git, dass Kernel-Hüter Linus Torvalds selbst geschrieben hat.

Bei den verteilten Systemen besitzt jeder Entwickler ein eigenes Repository, das nur bei Bedarf mit den anderen synchronisiert wird. Ein privilegiertes Master-Repository führt letztlich die autorisierte Fassung, von der die Releases ausgehen. Zwei Artikel im Linux-Magazin geben einige weitere Informationen zu verteilten Versionskontrollsystemen am Beispiel von Arch/Monotone [4] und Git [5]. Einen ausführlichen Vergleich von Versionskontrollsystemen gibt [6], auch wenn es sich nicht auf dem allerneuesten Stand befindet und Git beispielsweise nicht aufführt.