Ordentliche Buchführung

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/