Nicht nur Programmierer kennen das Problem: Sobald es mehrere Versionen einer Datei gibt, bricht Chaos aus. Subversion steuert dagegen.

Sobald Sie über das lokale Netzwerk oder das Internet mit mehreren Menschen an einem Projekt arbeiten, kommt es zur Konfusion: An welcher Datei arbeitet der Kollege eigentlich gerade, ist das jetzt meine letzte Version der Datei? Die meisten Menschen basteln in Handarbeit eine Notlösung, um wenigstens Veränderungen in den eigenen Dateien im Blick zu behalten. Macht das jeder, dann gibt es am Ende 20 Bastel-“Lösungen” – und noch immer weiß niemand, woran der Nachbar gerade arbeitet.

Eine Versionierungssoftware wie Subversion (kurz SVN) [1] (Abbildung 1) behält die Übersicht und nimmt Ihnen diese Arbeit ab. Sie müssen zwar ein paar neue Befehle lernen, das Wissen hilft Ihnen aber auch in anderen Situationen, etwa:

• wenn Sie auf einer Webseite den lapidaren Satz lesen, dass Sie die neueste Version der Software ja “aus dem SVN ziehen können”;
• wenn Sie kein Programmierer sind, sondern Texte schreiben, Rechnungen verwalten oder Projekte am Computer planen;
• wenn Sie Zwischenstände Ihrer Dateien aufbewahren wollen.

Abbildung 1: Sie können Subversion auch aus dem Quellcode selbst kompilieren, die meisten Distributionen stellen aber fertige Pakete bereit.

Bei SVN handelt es sich um eine Antwort auf CVS (Concurrent Versions System) [2], eine in Entwicklerkreisen weit verbreitete und nach wie vor beliebte Versionierungsverwaltung. Subversion will die Mängel von CVS beheben und steht unter einer Apache/BSD-Lizenz.

Alles ist ein Kreis

Subversion generiert gewöhnlich ein Projektarchiv (das Subversion-Repository) auf das unterschiedliche viele SVN-Clients zugreifen. Sie können das Archiv auch mittels Apache und dem Modul mod_dav_svn als Server auf einem Rechner im Internet betreiben, etwa bei Freshmeat.net oder Sourceforge.net. Arbeiten Sie allein, richten Sie am besten ein lokales Subversion-Archiv auf Ihrem Rechner ein.

Zunächst legen Sie ein Repository an. Dieses verstaut dann die zu bearbeitenden Dateien in einer internen Datenbank. Standardmäßig nutzt SVN zwar mittlerweile die FSFS-Datenbank – einige Nutzer setzen aber noch auf die ältere Berkeley-Database.

Zum Bearbeiten der Daten fordern die SVN-Clients zunächst eine Arbeitskopie beim Subversion-Archiv an (“Checkout”) und legen diese auf dem lokalen Rechner ab. Sie modifizieren die Dateien und pflegen sie dann wieder in das Projektarchiv ein, was unter dem Begriff “Commit” firmiert (Abbildung 2). Subversion schaut sich die veränderten Dateien an und verteilt – so es keine Konflikte gibt – neue Revisionsnummern (siehe Kasten “Revisionismus”).

Abbildung 2: So sieht – stark vereinfacht – die Arbeit mit einem SVN-Archiv aus: Checkout, Bearbeiten, Update, Commit.

Jeder darf sich ohne falsche Skrupel beliebig viele Arbeitskopien vom Server holen und diese verändern – so lange die Betreiber des Repositories das nicht mit Hilfe von Passwörtern verhindern. Subversion ficht das nicht an. Es interessiert sich erst für die Daten, wenn Sie versuchen, diese wieder einzuchecken. Die meisten freien Projekte erlauben jedem das Auschecken, Einchecken dürfen hingegen nur angemeldete Entwickler.

Statt Veränderungen blind zu übernehmen, prüft Subversion, ob es mittlerweile eine neue Version der Software gibt. Daher bringen Sie als Entwickler Ihre Daten vor dem Einchecken über ein Update auf den neuesten Stand. Denn bastelt genau in diesem Augenblick ein anderer Entwickler an derselben Datei wie Sie, womöglich am gleichen Problem, kommt es zum Konflikt. Subversion sieht nun zwei Versionen derselben Datei und weiß nicht, welche es übernehmen soll. Also lehnt es die Übermittlung ab, markiert die beiden Stellen im Code (Abbildung 3) und überlässt es den Entwicklern, das weitere Vorgehen zu klären. Ohne direkte Kommunikation geht es also mitunter doch nicht.

Schema F

SVN schert sich nicht darum, was für Daten es verwaltet. Allerdings gibt es Konventionen, denen die meisten Subversion-Archive folgen. In den Repositories begrüßen einen deshalb drei Ordner namens trunk, tags und branches (Abbildung 4). Unter trunk finden Sie die aktuelle Version der Software, an der Sie gewöhnlich arbeiten. Gibt es irgendwann eine stabile Zwischenversion, kopieren Sie diese über svn copy trunk tags/version-0.1 in den Ordner tags, dorthin gehören also Zwischenstände. Im Verzeichnis branches bilden die Entwickler Zweige, das heißt, hier entwickeln sie Ableger der Trunk-Version parallel weiter. Diese Versionen dienen der Fehlersuche (Bugfix), der Erprobung von Updates oder für Experimente.

Abbildung 4: Für die Struktur von Subversion-Repositories haben sich als Konvention drei Ordner namens Trunk, Tags und Branches durchgesetzt.

Subversion installieren

Um Subversion zu nutzen, spielen Sie es einfach über den Paketmanager ein. Nutzer von Open Suse installieren die Pakete subversion und subversion-server, Ubuntu-Nutzer spielen subversion ein. Mit Kdesvn, Rapidsvn, Websvn gibt es auch zahlreiche grafische SVN-Oberflächen. Wir behandeln hier nur die Text-Variante, denn im Server-Bereich fehlt nicht selten der Zugriff auf grafische Werkzeuge. Zunächst erfahren Sie, wie Sie ein Repository einrichten, das andere Mitarbeiter via Internet oder LAN erreichen.

Fern und doch so nah

Wer im Internet oder im LAN ein SVN-Repository anbietet, wählt am besten die Kombination aus dem Webserver Apache und dem Apache-Modul mod_dav_svn. Wollen Sie SVN nur lokal verwenden, springen Sie weiter zur übernächsten Überschrift.

Hier lesen Sie, wie Sie unter Ubuntu Feisty Fawn einen Webserver mit einem Repository aufsetzen. Nutzer von Open Suse 10.2 können sich zwar an diesen Schritten orientieren, konkreter hilft ihnen jedoch ein Dokument, das Open Suse bereits an Bord hat. Es beschreibt einen funktionierenden Weg zum Einrichten eines Subversion-Archivs (siehe Kasten SVN-Server unter Open Suse 10.2).

Ubuntu-Anwender installieren zunächst die Pakete apache2 und libapache2-svn. Dann legen Sie über sudo mkdir /var/svn ein Verzeichnis für das zukünftige Subversion-Archiv an. Welches Sie auswählen, bleibt Ihnen überlassen, wir nehmen /var/svn.

Der Befehl sudo svnadmin create /var/svn legt in dem Ordner ein leeres Repository an, das Sie über sudo chown -R www-data /var/svn mit den Rechten des Apache-Servers versehen. Wer lesend und schreibend auf das Subversion-Archiv zugreifen darf, regeln Sie über die Rechteverwaltung von Apache.

Zunächst kümmern Sie sich um die SVN-Unterstützung. Dazu öffnen Sie die zuständige Konfigurationsdatei in einem Editor: sudo pico /etc/apache2/mods-enable/dav_svn.conf. Kommentieren Sie die Einträge so aus, dass sie aussehen, wie in Listing 1.

# SVN-Konfiguration für Apache
<Location /svn>
        DAV svn
        SVNPath /var/svn
        AuthType Basic
        AuthName "Subversion Repository"
        AuthUserFile /etc/apache2/svn_passwd
        AuthzSVNAccessFile /etc/apache2/svn_access
</Location>
<LimitExcept GET PROPFIND OPTIONS REPORT>
        Require valid-user
</LimitExcept>

Die Zeile SVNPath verweist auf Ihr Repository unter /var/svn, die Einträge hinter AuthName und AuthzSVNAccessFile zeigen auf zwei Dateien, die Sie nun erstellen.

$ sudo touch /etc/apache2/svn_passwd svn_access

In svn_access tragen Sie die Zugriffsrechte der Nutzer ein, ihre Passwörter landen in der Datei svn_passwd.

Damit nicht jeder Außenstehende in das Repository schreibt, richten Sie über die Software Htpasswd passwortgeschützte Zugriffsberechtigungen ein. Geben Sie sudo htpasswd -cm /etc/apache2/svn_passwd testuser ein, um einen Benutzer namens testuser anzulegen. Was dieser Benutzer darf, bestimmen Sie in der zweiten Datei svn_access. Dort hinein kommt folgende Zeile:

[/]
* = r
testuser = rw

Der Anwender testuser besitzt nun Lese- und Schreibrechte im Verzeichnis /var/svn, der Rest der Welt darf lesend auf das Repository zugreifen. Über htpasswd -m – das c fehlt hier – legen Sie weitere Nutzer an und justieren die Rechte entsprechend. Über [/trunk/Unterverzeichnis] vergeben Sie eine Lese- und Schreiberlaubnis für einzelne Unterordner.

Daten tanken

Noch gibt es nur ein leeres Repository, das Sie nun mit Daten füllen. Zuvor starten Sie über sudo /etc/init.d/apache2 force-reload den Webserver neu, dann folgt der Import-Befehl:

$ svn import /Pfad/zu/mein_testprojekt http://127.0.1.1/svn/trunk -m "Erstimport" --username Testuser

Er sorgt dafür, dass alle Daten unterhalb von mein_testprojekt im lokalen Subversion-Repository landen und zwar im Verzeichnis trunk. Um sich von der erfolgreichen Einrichtung des Repositories zu überzeugen, geben Sie im Browser http://127.0.1.1/svn ein. Da alle Nutzer über Leserechte verfügen, sollte nun der Subversion-Server mit dem Verzeichnis trunk erscheinen (Abbildung 5). Andernfalls starten Sie den Apache-Server noch einmal neu.

Abbildung 5: Erster Kontakt: Haben Sie erfolgreich einen Satz an Daten importiert, durchstöbern Sie den Dateibaum mit einem Browser.

Betreiben Sie den Apache-Server im Internet, wollen Sie sicher, dass externe Mitarbeiter das Repository auch von Außen erreichen. Sie brauchen eine feste und ständig erreichbare IP-Adresse oder einen festen Domain-Namen, worum sich Services wie Dyndns.org [3] kümmern. Andere Benutzer erreichen Ihr SVN-Archiv dann etwa über http://meinsvn.dyndns.org/svn oder im lokalen Netzwerk über http://192.168.1.22/svn. Eventuell müssen Sie den von Apache angebotenen Port forwarden oder die Firewall so einrichten, dass sie eingehende Verbindungen auf den Ports 80 und 443 akzeptiert.

Um die Daten zwischen den einzelnen Benutzern und dem Repository sicher auszutauschen, richten Sie dann noch das SSL-Modul für Apache ein. Wie das geht, zeigt für Ubuntu der Kasten “SSL-Support”. Nutzer von Open Suse finden ein entsprechendes Howto im Open-Suse-Wiki [4].

$ sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

$ sudo ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/ssl

NameVirtualHost *:443
<VirtualHost *:443>

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem

NameVirtualHost *:80
<VirtualHost *:80>

$ sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

sudo chmod 600 /etc/apache2/ssl/apache.pem

Lokales Subversion-Archiv anlegen

Wollen Sie SVN nur auf Ihrem Privatrechner nutzen, brauchen Sie keinen Subversion-Server. Sie nutzen auch hier das Programm Svnadmin und geben einfach folgende Zeile ein:

$ sudo svnadmin create /home/User/mein_repository

Der Befehl legt die Repository-Struktur in Ihrem Home-Verzeichnis an. Die dabei erzeugten Dateien und Ordner dienen lediglich der Verwaltung der eigentlichen Daten. Es handelt sich etwa um die Datenbank, einige Konfigurationsdateien und einen Ordner für Hook-Skripte.

Lokal Daten tanken

Um Daten in das lokale Repository einzupflegen, hilft wieder der Import-Befehl.

$ svn import /Pfad/zu/mein_testprojekt file:///home/User/mein_repository/trunk -m "Erstimport"

Das Kommando importiert alle Dateien unterhalb des Ordners mein_testprojekt und legt Sie – mit einem Kommentar (-m) versehen – im Verzeichnis trunk im lokalen Subversion-Archiv ab.

Wie Sie sehen, beginnen die meisten Befehle, die das Repository betreffen, mit svn. Die Übersichtstabelle “Weitere SVN-Befehle” am Ende des Artikels listet noch mehr SVN-Kommandos auf und erklärt kurz, was diese bewirken.

Check it out!

Um nun mit den importierten Daten zu arbeiten, legen Sie eine lokale Arbeitskopie an. Erzeugen Sie dazu einen Ordner namens arbeitskopie im Home-Verzeichnis. Angenommen, die Software befindet sich auf einem entfernten Server – sei es im LAN oder im Internet. Dann checken Sie den gesamten Code über folgenden Befehl aus.

$ svn co https://mysvn.dyndns.org/svn arbeitskopie

Die Abkürzung co steht für checkout. Dann folgt das verwendete Protokoll – wahlweise auch SVN oder HTTP – und die Adresse des Servers. Subversion holt alle Dateien unterhalb des genannten Ordners ab und kopiert sie in das gerade angelegte Verzeichnis arbeitskopie – der Name darf auch anders lauten.

Lokale Einsichten

Um Dateien aus einem lokalen Repository auszuchecken, nutzen Sie einen ähnlichen Befehl:

$ svn co file:///var/svn arbeitskopie

Hier tauschen Sie lediglich die URL gegen einen lokalen Pfad aus.

Dateien bearbeiten

Nun bearbeiten Sie eine Datei. Wechseln Sie in den Ordner arbeitskopie, öffnen Sie eine der dort aufbewahrten Dateien und schreiben einen Kommentar hinein. Das richtet keinen Schaden an, genügt aber als Modifikation.

Während Sie die Datei noch verändern, checkt vielleicht gerade ein anderer Entwickler seine Modifikationen in das SVN-Archiv ein. Um den aktuellen Status der lokalen Arbeitskopie und des entfernten Repositories zu erfragen, geben Sie svn status -u ein. Der Befehl gibt als Ergebnis M TODO an. Das bedeutet, Sie haben lokal eine Datei namens TODO verändert. Lautet die Antwort indes wie in Abbildung 6, war offensichtlich ein anderer Entwickler schneller als Sie. Das Sternchen verweist auf eine Änderung im Subversion-Archiv. Sie wissen allerdings nicht, welche Datei er verändert hat und versuchen ein Update per svn update.

Abbildung 6: Die Statusabfrage zeigt: Sowohl lokal als auch im Repository wurde die Datei TODO verändert.

Den Befehl müssen Sie – wie andere SVN-Befehle auch – aus dem Arbeitsverzeichnis arbeitskopie heraus aufrufen. Andernfalls weiß Subversion nicht, auf welches Repository er sich bezieht. Diese Information enthält das automatisch generierte Verzeichnis .svn.

Sie haben Pech, denn das “gefürchtete” C taucht auf: Es liegt ein Konflikt vor. Offensichtlich kollidieren die Veränderungen in zwei Dateien miteinander. Schauen Sie nun in Ihrem lokalen Verzeichnis nach, gibt es dort plötzlich vier Files: TODO, TODO.mine, TODO.r21 und TODO.r22. In der Datei TODO hebt Subversion die beiden divergierenden Einträge deutlich hervor, es handelt sich zum Glück nur um zwei harmlose Kommentare (Abbildung 7).

Abbildung 7: Zwei Kommentar überschneiden sich zufällig. Das Problem lässt sich leicht lösen, danach geben Sie »svn resolved« ein.

Sie überarbeiten die Datei TODO und teilen Subversion dann mit, dass Sie das Problem erledigt haben:

$ svn resolved TODO

Subversion versteht und schreibt: Konflikt von 'TODO' aufgelöst. Beide Kommentare koexistieren nun friedlich nebeneinander. Endlich checken Sie Ihre Änderung ein.

$ svn commit -m "endlich_gehts" TODO

Die Datei gelangt als neue Revision ins Archiv (siehe Kasten “Revisionismus”) . Arbeiten Sie dann ein anderes Mal weiter an Ihrer lokalen Arbeitskopie, macht es Sinn, den Code vorher über ein Update auf den neuesten Stand zu bringen.

Verschiebebahnhof

Neue Dateien im Verzeichnis arbeitskopie bemerkt Subversion erst, wenn Sie den Befehl svn add Datei eingeben, der neue Dateien und Verzeichnisse zunächst markiert. In das Subversion-Archiv gelangen sie erst über das “Commit”-Kommando.

Gewöhnlich kopieren, bewegen, löschen und ergänzen alle SVN-Befehle das angegebene Verzeichnis rekursiv – mit Unterverzeichnissen und deren Inhalten. Über die Option -n verhindern Sie das.

Um Dateien und Ordner wieder zu löschen, gibt es den Delete-Befehl. Die lokale Variante sieht folgendermaßen aus:

$ svn delete file:///var/svn/projektname -m "Alles_löschen"

Ein ganz ähnlicher Befehl löscht Dateien vom Subversion-Server:

$ svn delete https://mysvn.dyndns.org/svn -m "Alles_löschen"

Bitte beachten Sie dabei, dass der Löschbefehl zwingend auch einen Kommentar erfordert.

Fazit

Es ließe sich noch wesentlich mehr über Subversion schreiben, allerdings würde das den Rahmen der Einführung sprengen. Viele Subversion-Befehle sehen aus wie Unix-Befehle mit einem svn davor. So gibt es svn mkdir, svn cat, svn move oder svn copy. Dank des Präfix kann Subversion die Änderungen verfolgen.

Doch die Software kann noch mehr: Sie “locken” Dateien, um sie für die Zeit der Bearbeitung für andere Entwickler zu sperren. Über svn status, svn blame, svn info und svn list sammeln Sie Informationen über den Zustand des Repositorys. Nicht zuletzt erlaubt Subversion den Einsatz von Properties. Wer ernsthaft und produktiv mit der Software arbeiten will, findet zahlreiche Online-Ressourcen [5] und Literatur ([6],[7]) zum Thema – auch Subversion will gelernt sein.