Versionsverwaltung ist weder kompliziert noch ausschließlich für Programmierer gedacht: Tools wie Subversion archivieren unkompliziert alle Dateien, von denen es unterschiedliche Versionen gibt.

CVS [1] steht für Concurrent Versions System, SVN für Subversion [2]. Bei beiden handelt es sich um Versionsverwaltungen, mit denen zum Beispiel Entwicklerteams ihre Arbeit am Programmcode koordinieren und den Codebestand verwalten. Die CVS- oder auch SVN-Version eines Programms ist also diejenige Version, die selbst Änderungen der letzten Minuten enthält – mit den bekannten Auswirkungen auf die Stabilität.

Die Hauptaufgabe der Versionskontrolle besteht darin, die unterschiedlichen Varianten der oft zahlreichen Dateien eines Projekts übersichtlich und in ihrer Entstehungsgeschichte nachvollziehbar aufzubewahren. Besonders wichtig ist das bei Programmierprojekten, wo eine kleine Modifikation oft viele, schwer vorherzusehende Auswirkungen hat.

Doch es spricht nichts dagegen, diese zusätzliche Sicherheit auch in ganz anderen Bereichen zu nutzen: Bei kreativen Arbeiten wie beim Schreiben oder beim Bildbearbeiten fördert sie die Spontaneität – die früheren Versionen sind ja nicht verloren.

Bearbeiten Sie in Gimp nur eine einzelne Datei, mag es genügen, neue Versionen jeweils unter einem neuen Namen zu speichern. Doch echte Versionkontrolle bietet einige Vorteile (Abbildung 1): So erlaubt es die Software, jede Version mit einem, wenn nötig, längeren Kommentar versehen. Außerdem liegen die vielen Dateiversionen, solange Sie sie nicht brauchen, in der Datenbank und erschweren so nicht die Übersicht.

Abbildung 1: Zu jeder Datei sehen Sie in SVN und CVS einen Logeintrag mit allen Änderungen, Äderungsdatum und dem Namen des Bearbeiters. Bei sich überschneidenden Änderungen meldet das Tool einen Konflikt und stellt die konkurrierenden Teile einander gegenüber.

Bei CVS und SVN handelt es sich um frei verfügbare Tools, die auf fast allen relevanten Betriebssystemen laufen – darunter Linux und BSD, aber auch Windows, Mac OS X, BeOS und OS/2. SVN, im Jahr 2000 von CollabNet entwickelt, versteht sich als Nachfolger von CVS und übernimmt größtenteils dessen Features, bringt jedoch eine Reihe von Verbesserungen mit. Die wichtigste ist, dass sich Dateien in einem mit SVN verwalteten Verzeichnisbaum verschieben und umbenennen lassen, während dies bei CVS noch nicht möglich war, ohne dass die Versionsinformationen verloren gingen.

Grundlagen

So funktioniert das Arbeiten mit einer Versionsverwaltung: Um auf die Dateien, die zunächst nur in der Datenbank liegen, zugreifen zu können, steht ganz am Anfang der sogennannte Checkout (Befehl: svn checkout). Die Versionsverwaltung kopiert dabei alle Projektdateien in ein lokales Verzeichnis. Die Verzeichnisse .svn beziehungsweise CVS enthalten Verwaltungsinformationen, die der Benutzer nicht verändern darf.

Arbeiten Sie im Team, so laden Sie mit einem Update (svn update) die Änderungen, die andere Benutzer in die Datenbank der Versionsverwaltung übertragen haben. Ein Commit (svn commit) hingegen speichert eigene Änderungen in der Datenbank, dem so genannten Repository (Abbildung 2).

Arbeiten mehrere Entwickler an einem Projekt, so kommt es natürlich vor, dass mehrere Personen gleichzeitig die selbe Datei verändern. Hier zeigt sich erst die eigentliche Stärke einer Versionsverwaltung: Greifen mehrere Personen ohne Versionsverwaltung auf eine Datei zu, so überschreiben sie häufig die Änderungen der anderen. Zumindest für Textdateien in CVS und SVN gilt: Betreffen gleichzeitige Änderungen unterschiedliche Stellen in der Datei, so fügt die Versionsverwaltung das Resultat automatisch richtig zusammen.

Auch wenn dies bei Binärdateien oder bei sich überschneidenden Änderungen nicht funktioniert, verhindert SVN mit der Meldung Datei bleibt in Konflikt zumindest das wechselseitige Überschreiben. Im Arbeitsverzeichnis liegen dann, wie in Abbildung 1 zu sehen, unverändert die von Ihnen bearbeitete Version (aepfel.png), die Version des Teamkollegen (aepfel.png.r5), sowie die Revision, auf der beide Änderungen basieren (aepfel.png.r4). Die Versionsverwaltung kennzeichnet die Dateien durch Anhängen der Revisionsnummer an den Dateinamen.

Abbildung 2: Ein zentrales Versions-Repository verwaltet die Arbeit mehrerer Benutzer. Das Repository enthält alle Versionen der Dateien und Daten wie Logmeldungen. In den Arbeitskopien liegen nur die aktuellen Versionen, um das Bearbeiten nicht zu erschweren.

SVN-Repository einrichten

Im Folgenden beschränkt sich der Artikel auf die Beschreibung des moderneren und leistungsfähigeren SVN. Wenn in vielen Open-Source-Projekten noch immer CVS zum Einsatz kommt, dann meist vor allem aus Tradition.

Voraussetzung für das Arbeiten mit SVN ist das Programmpaket subversion. Um Subversion nutzen zu können, richten Sie zuerst mit svnadmin create /Pfad/zum/Repository ein Repository ein. Listing 1 zeigt den Befehl und die Verzeichnisstruktur, die im neu angelegten Repository entsteht. Es dient als Container für die Projektdateien.

SVN nutzt zum Speichern jedoch eine Datenbank (Berkley DB), so dass die Dateien auch bei gefüllten Repositories nicht im Dateisystem erscheinen. Dennoch muss jeder Nutzer, der auf das Repository zugreift, Schreib- und Leserechte besitzen. Außerdem arbeitet die Datenbank nur korrekt, wenn das Repository-Verzeichnis nicht über ein Netzwerkdateisystem eingebunden ist. Diese Einschränkung lässt sich umgehen, wenn Sie svnadmin-beim Erstellen des Repositorys mit dem zusätzlichen Parameter --fs-type fsfs aufrufen.

$ svnadmin create /home/jploetner/SVN
$ ls /jploetner/SVN
README.txt
conf/
dav/
db/
format
hooks/
locks/

Arbeiten mit SVN

Nach dem Erstellen ist das Repository zunächst leer. Um es mit bereits vorhandenen Dateien zu füllen, benutzen Sie den Befehl svn import. Nennen Sie – wie beim normalen Kopieren von Dateien – Quelle und Ziel des Imports: svn import /home/jploetner/projekte file:///Pfad/zum/Repository -m "initialer Import" übergibt alle Dateien aus dem Verzeichnis Projekte an die Versionsverwaltung. Den Text hinter dem Parameter -m trägt SVN als Kommentar für die Grundversion (Revision 1) der Projektdateien ein.

Von jetzt an Arbeiten Sie nicht mehr mit den Dateien in /home/jploetner/projekte, Sie können das Verzeichnis löschen. Erstellen Sie einen neuen Ordner für die Arbeitskopien (den Checkout) der Projektdateien und wechseln Sie auf der Konsole in das neue Verzeichnis. Auf den Befehl svn checkout file:///Pfad/zum/Repository/ antwortet SVN mit der Meldung Checked out revision 0 und schreibt alle Projektdateien sowie einige Verwaltungsinformationen in einem versteckten Ordner in das aktuelle Verzeichnis. Dies sind die Arbeitskopien aller Dateien aus dem Repository, die Sie wie gewohnt bearbeiten.

Jede Veränderung melden Sie der Versionsverwaltung mit svn commit -m "Kommentar" Pfad/zur/Datei. Nutzen Sie dabei die Möglichkeit, jeder Revision ausführliche Kommentare hinzuzufügen, die die Änderungen dokumentieren. Kommentare sind besonders bei Teamprojekten wichtig, doch auch wenn Sie allein arbeiten, erleichtern sie es, den Überblick über die sich mehrenden Versionen zu behalten.

Möchten Sie dem Projekt eine neue Datei hinzufügen, so erstellen Sie diese zunächst im Arbeitskopien-Ordner. svn add Dateiname teilt der Versionsverwaltung mit, dass Sie diese Datei in Zukunft verwalten soll, schreibt deren Inhalt jedoch noch nicht in die Datenbank. Erst der Befehl svn commit -m "Kommentar" Dateiname übergibt die erste Version an das Repository. svn delete Dateiname löscht eine Datei aus dem Repository, allerdings nicht aus dem Arbeitskopien-Ordner. Erst nach einem Commit verschwindet auch die Arbeitskopie. Beispiele für beide Befehle zeigt Listing 2.

$ svn add artikel2.txt
A      artikel2.txt
$ svn commit -m "Init-Version" artikel2.txt
Adding         artikel2.txt
Transmitting file data .
Committed revision 1.
$ svn delete artikel2.txt
D      artikel2.txt

Mit svn move alterName neuerName benennen Sie Dateien um. SVN löscht die alte Datei und erstellt Sie mit neuem Namen (Listing 3). Anders als bei CVS gehen dabei die Versionsinformationen nicht verloren.

$ svn move neu.txt alt.txt
A       alt.txt
D       neu.txt
$ svn commit -m "Umbennenen von neu.txt in alt.txt"
Adding         alt.txt
Deleting       neu.txt
Transmitting file data .
Committed revision 3.

Nur ein Projekt pro Repository? Das muss nicht so sein. Übergeben Sie SVN, wenn es mehrere Projekte verwalten soll, einfach den projekte-Grundordner, in dem zum Beispiel die Unterordner artikel_user, webprojekt und fotoprojekt liegen. Sie können dann einzelne Projekte auschecken, indem Sie den an den Pfad/zum/Repository noch den Unterordner des jeweiligen Projekts anhängen: svn checkout Pfad/zum/Repository/webprojekt extrahiert nur den Unterordner webprojekt.

SVN ist für die Teamarbeit ausgelegt. Wenn Sie Änderungen, die Ihre Mitstreiter vorgenommen haben, ansehen möchten, holen Sie diese über den Befehl update aus der Datenbank. Bevor Sie dies tun, vergessen Sie nicht, eigene Änderungen mit commit in die Versionshistory zu schreiben. svn update bringt daraufhin das Arbeitsverzeichnis auf den neuesten Stand. Es lädt aber nicht alle, sondern nur die veränderten Dateien herunter. Besonders wenn das Repository auf einem anderen Rechner im Netz steht, ist dies wesentlich effektiver. Möchten Sie nur bestimmte Dateien aktualisieren, so können Sie deren Namen hinter update als Parameter angeben.

Was macht den Unterschied?

Es ist nicht ganz leicht, den Überblick über die Veränderung der Dateien zu behalten. Der Befehl diff zeigt die Unterschiede zwischen der lokalen Arbeitskopie und der Version im Repository. Dies veranschaulicht folgende Beispieldatei neu.txt mit dem Inhalt:

In dieser Datei stehen
drei
Zeilen

Verändern Sie nun den Inhalt der Arbeitskopie der Datei in

In dieser Datei stehen
vier
Zeilen

dann liefert svn diff neu.txt eine Ausgabe, wie sie Listing 4 zeigt. SVN nennt zuerst den Dateinamen, dann die beiden Versionen, die es vergleicht (revision 2 im Repository gegen die working copy). Diff teilt die Datei in Blöcke ein, die es durch Zeilen, die mit @@ enden und beginnen, markiert.

-<§§I>von,bis<§§I> zeigt die Zeilennummern des Blocks in revision 2, +<§§I>von,bis<§§I> die Zeilennummern in der working copy. Der Block wurde nicht verschoben, die Zeilennummern sind daher gleich geblieben. Dass sich der Text drei zu vier verändert hat, symbolisiert SVN durch + und - vor der entsprechenden Zeile.

$ svn diff neu.txt
Index: neu.txt
===================================================================
— neu.txt     (revision 2)
+++ neu.txt     (working copy)
@@ -1,3 +1,3 @@
 In dieser Datei stehen
-drei
+vier
 Zeilen.

Wem diese sogenannte Unified-Diff-Notation zu kompliziert ist, der sollte ein grafisches SVN-Backend benutzen. Abbildung 3 zeigt das gleiche Beispiel in Kdesvn [3]. Der entsprechende Konsolenbefehl lautet svn status Pfad/zum/Arbeitsverzeichnis. Informationen zur Bedeutung der Buchstabensymbole, mit denen SVN die Änderungen dabei kennzeichnet, finden Sie unter [4].

Abbildung 3: Kdesvn bietet eine übersichtliche, grafische Diff-Anzeige.

Eine Alternative zu Kdesvn bieten das Konqueror-Plugin KSvn [5], die Qt-basierten Programme eSvn [6] und QSvn[7] sowie das Java-Programm Jsvn [8]. Auch die Entwicklungsumgebungen Kdevelop und Eclipse (Plugins: Subversive [9] oder Subclipse [10]) integrieren eine graphische SVN-Unterstützung.

Selbstverständlich ist auch ein Vergleich mit älteren Version möglich: svn diff -r Version vergleicht die Arbeitskopie mit der angegebenen Version, svn diff -r Version1:Version2 vergleicht zwei Versionen im Repository.

Anders als bei CVS gelten die Versionsnummern in SVN global: Jeder Commit erhöht die Versionsnummer aller Dateien im Repository. Daher ist es bei SVN nicht möglich, frühere Versionen einzelner Dateien abzurufen: Nur Gesamtzustände des Repositorys vor einem bestimmten Commit lassen sich wiederherstellen (svn update -r Revision). Einzelne Dateien können Sie aber über den Befehl svn cat -r RevisionDateiname anzeigen und über die Umleitung der Befehlsausgabe (svn cat -r RevisionsnummerDateiname > Dateiname) im Arbeitsverzeichnis speichern. Die Versionsverwaltung zählt diese Datei nach einem erneuten Commit allerdings schlicht als neue Version.

SVN im Netz

Eine Versionsverwaltung dient häufig als zentrale Anlaufstelle für ein Entwicklerteam. Es gibt daher viele Möglichkeiten, das Repository im Netz bereitzustellen. Das Paket SVN bringt mit svnserve bereits einen einfach zu konfigurierenden Netzwerkdienst mit. Alle erforderlichen Einstellungen nehmen Sie in den Dateien conf/svnserve.conf und conf/passwd vor. Eine svnserve.conf mit dem Inhalt aus Listing 5 erlaubt nur den in passwd (Listing 6) festgelegten Usern einen Zugriff auf das Repository. Nach dem Start von svnserve -d können Sie in SVN-Befehlen als Pfad zum Repository svn://Rechner/lokaler/Pfad/zum/Repository angeben.

### conf/svnserve.conf
[general]
password-db= passwd
realm = example realm  ### eine Art "Namespace"
anon-access = none     ### für anonymen Lesezugriff: "read"
auth-access = write

### conf/passwd
[users]
user   = secret  ### User / Passwort
user2 = secret2  ### User / Passwort

svnserve erlaubt auch das Tunneln der Verbindung über Ssh und bietet damit eine abhörsichere Verbindung (Anleitung, englisch: [11]). Außerdem gibt es eine Reihe von Weboberflächen, mit denen sich der Inhalt des Repositorys im Webbrowser anzeigen lässt: CVSWeb (für CVS), ViewCVS (für CVS und Subversion) und WebSVN (für Subversion, Abbildung 4). Letzteres erzeugt sogar RSS-Feeds.

Abbildung 4: WebSVN ermöglicht Zugriff auf Subversion-Repositorys mit dem Webbrowser.

Und CVS?

SVN liegt seit Februar 2004 in einer stabilen Version vor. Der Umstieg von CVS fällt leicht, da SVN die meisten Befehle unverändert übernimmt. SVN bietet gegenüber dem Open-Source-Urgestein CVS eine Reihe Vorteile: Dateien lassen sich umbenennen und verschieben, und SVN ist sicherer und effektiver im Umgang mit Binärdateien. Zudem funktioniert der commit-Vorgang bei Subversion atomar: Dies bedeutet, dass er entweder vollständig oder gar nicht durchgeführt wird. Besonders bei Commits über das Netzwerk bietet dies zusätzliche Sicherheit.

Wer trotzdem noch CVS benutzt, tut dies aus Tradition oder aus ganz speziellen Bedürfnissen: CVS Repositorys benötigen weniger Speicher und obwohl Subversion als ausgereift gilt, sagt man CVS noch einen Tick mehr Stabilität nach.

Weitere Informationen zum Thema Versionsverwaltung bieten die Bücher [12], [13] und [14], eine ausführliche Anleitung zu SVN finden Sie online unter [15]. Zwei Artikel in LinuxUser 05/2005 liefern eine Einführung in die Versionskontrolle [16] und das handliche Versionskontrollsystem RCS [17].