Veränderungen festhalten

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.