Wenn man mit vielen Dokumenten gleichzeitig arbeitet, versucht man, verschiedene Versionen der Datei im Dateisystem vorzuhalten. Häufig führt man eine entsprechende Dateinamenskonvention ein, bei der man verschiedene Versionen einer Datei anhand einer laufenden Nummer und eines Datums erkennen kann. Manchmal kann es jedoch passieren, dass aus Unachtsamkeit eine Version überschrieben wird, die man eigentlich retten möchte, oder dass das Office-Dokument kaputt geht. Nicht immer kann man alte Stände aus älteren Versionen wieder herstellen.

Dabei existieren kostenlose Softwaretools wie Subversion, die einem die mühsame Arbeit der Versionierung abnehmen können. Subversion verwaltet Dokumente in einem so genannten Repository. Dabei handelt es sich um eine Datenbank, die Text- und Binärdateien vorhält. Wenn man mit den Dateien arbeiten und sie ändern möchte, muss man eine Arbeitskopie auschecken, also aus der Datenbank auslesen. Anschließend werden Änderungen wieder an die Datenbank übergeben. Die Datenbank legt dabei eine neue Revision für die geänderten Dateien an, wobei jede Revision eine laufende Nummer erhält. Alte Dateistände gehen dabei ncht verloren, sondern werden vorgehalten und können jederzeit wieder ausgelesen werden.

Das Besondere an Subversion ist die Art und Weise, wie Textdateien verwaltet werden. Bei einer Revision wird nicht jedes Mal eine vollständige Kopie der Datei in die Datenbank eingelesen. Stattdessen werden lediglich die Unterschiede zwischen der neuen und der vorhergehenden Revision gespeichert. Beim Auschecken der aktuellen Revision werden dabei die Versionsinformationen wieder zu einer vollständigen Datei zusammengelegt.

Bei Binärdateien ist diese Vorgehensweise allerdings nicht möglich. Für diese Dateien werden direkt komplette Kopien angelegt. Subversion kann seine Stärken also vor allem bei textbasierten Dateiformaten wie Klartext, XML oder HTML ausspielen.

Lokales Repository für Dokumente anlegen

Um ein lokales Repository im Home-Verzeichnis anzulegen, kannst du folgenden Befehl in die Linux-Konsole deines Vertrauens (beispielsweise bash) eingeben:

user@linux:~$ svnadmin create LocalRepos

In deinem Home-Verzeichnis wurde jetzt ein neues Verzeichnis mit dem Namen LocalRepos/ angelegt. In diesem Verzeichnis werden die ganzen Versionierungsinformationen durch Subversion abgelegt und verwaltet. Da dies vollkommen automatisch passiert, brauche ich den Aufbau dieses Verzeichnisses nicht vorzustellen. Näheres zum Aufbau des Verzeichnisses kann man jedoch im Buch , Kapitel 5, nachlesen.

Dokumente in das Repository importieren

Damit die Dokumente durch Subversion auch verwaltet werden können, müssen sie zunächst einmal in das Subersion importiert werden. Wenn die Dokumente für dein Projekt beispielsweise in deinem Home-Verzeichnis unter ~/Dokumente/Projekt-X/ liegen, kannst du einfach das komplette Verzeichnis Projekt-X/ importieren:

user@linux:~$ svn import ./Dokumente/Projekte file:///home/user/LocalRepos/trunk/Projekt-X

Im obigen Beispiel weißt du den Subversion-Client an, das Verzeichnis ./Dokumente/Projekt-X zu importieren. svn erwartet als drittes Argument die URL zum Subversion-Repository. Da das Repository in unserem Home-Verzeichnis liegt, geben wir als Protokoll file:// an und ergänzen es um den absoluten Pfad zum Repository. Hinzu kommt noch der Pfad zum Verzeichnis, in welches das Projekt angelegt werden soll. Im oberen Beispiel lautet es trunk/Projekt-X. Projekt-X ist also das Subversion-Verzeichnis, in dem die Versionen der Projekt-X-Dokumente gespeichert werden.

Verzeichnisse sind in Subversion eine Möglichketi, Projekte zusammenzufassen. Projekt-X ist beispielsweise das Verzeichnis, das unmittelbar alle Dateien und Unterverzeichnisse für ein Projekt “X” enthält. Bestimmte per Konvention vorgegebene Verzeichnisse helfen auch, Projekte im Subversion-Repository leichter zu verwalten.

trunk, tags und branches – Verzeichnisaufteilung im Subversion-Repository

Was hat es nun mit dem Verzeichnis trunk/ auf sich? Revisionssysteme wie Subversion teilen das Repository in drei verschiedene Bereiche auf:

• trunk/
• tags/
• branches/

trunk/ bezeichnet dabei den Hauptablageort für die Projekte. Wenn die bestimmte Revision eines Projektes aus dieser Hauptlinie Serien- oder Veröffentlichungsreife erreicht hat, erstellt man eine Kopie des Projektes im tags/-Verzeichnis. Spätere Änderungen in der Hauptentwicklungslinie im trunk/-Verzeichnis haben keinen Einfluss mehr auf die Projektkopie. Im Verzeichnis branch werden Verzweigungskopien aus der trunk-Hauptlinie gespeichert. Solche Kopien dienen beispielsweise den Zweck, tiefgreifende Änderungen am System vorzunehmen, ohne die anderen Entwickler bei der Arbeit am System zu stören. Für das hier beschriebene Beispiel ist jedoch lediglich das Projektverzeichnis im trunk/-Verzeichnis von Bedeutung.

Projekt aus dem Repository auschecken

Um das Subversion-Repository nutzen zu können, muss das zuvor importierte Verzeichnis Projekt-X aus dem Repository ausgecheckt werden. Auschecken bedeutet, dass eine vollständige Kopie aller Projektdateien angelegt wird, wobei in jedes augecheckte Verzeichnis ein Verzeichnis mit dem Namen .svn erstellt wird, das für die Verwaltung notwendige Metadaten enthält. Das ausgecheckte Verzeichnis stellt damit eine Arbeitskopie aus dem Subversion-Repository dar, die durch Subversion kontrolliert und verwaltet wird.

Um ein Projekt aus dem Repository auszuchecken, kann man folgenden Befehl benutzen:

user@linux:~/workspace$ svn checkout file:///home/user/LocalRepos/trunk/Projekt-X

Dieser Befehlt bewirk, dass das ausgewählte Verzeichnis Projekt-X in das aktuelle Arbeitsverzeichnis extrahiert wird. Dabei enthalten alle Verzeichnisse ein .svn-Verzeichnis.

Änderungen in Textdokumenten vergleichen

Von diesem Zeitpunkt an können alle Änderungen über Subversion verwaltet werden. Wenn eine Datei geändert worden ist, können die Änderungen von Textdateien mit dem diff-Befehl miteinander verglichen werden. Als Parameter erhält der Befehl den Namen der Datei für den die Versionsunterschiede angezeigt werden sollen:

user@linux:~/workspace/Projekt-X$ svn diff test.xml

Die Ausgabe des diff-Befehls könnte für die oben angegebene Datei wie folgt aussehen:

Index: test.xml
==============================================
--- test.xml (Revision 1)
+++ test.xml (Arbeitskopie)
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter>
-
+ <!--This is a comment -->
<title>Testkapitel</title/>
...


Die Konsolenausgabe stellt die geäderten Zeilen der Arbeitskopien mit denen der aktuellen Revision gegenüber, wobei die Zeilen der Arbeitskopie mit einem “+” beginnen, während die selben Zeilen der Revision von einem “-” eingeleitet werden. Die Zahlen zwischen den @-Zeichen geben darüber hinaus die Zeilen an, in denen zwischen Arbeitskopie und aktueller Revision ein Unterschied existiert.

Bei Binärdateien wie Grafik- und Fotodateien oder Office-Dokumenten ist eine solche Anzeige freilich nicht möglich. In solchen Fällen zeigt der diff-Befehl lediglich an, das die Arbeitskopie nicht mit der aktuellen Revision identisch ist.

Geänderte Dateiversion commiten

Im nächsten Schritt können die Änderungen aus der Arbeitskopie in das Repository commitet werden. Das bedeutet, dass die Änderungen an das Subversion übergeben werden. Bei jedem Übergabeschritt muss der Autor jedes Mal einen Versionskommentar angeben, damit festgehalten wird, welche Änderungen vorgenommen worden sind. Dies ist besonders dann wichtig, wenn viele Personen an einem Projekt beteiligt sind und man nachvollziehen möchte, wer was wann und warum geändert hat.

Um Änderungen an Subversion zu übergeben, kannst du folgenden Befehl in die Kommandozeile eingeben:

user@linux:~/workspace/Projekt-X$ svn commit test.xml

Nach der Eingabe dieses Befehls legt der subversion client eine temporäre Textdatei an und öffnet diese in einem Texteditor wie vi oder nano. In diese Textdatei kannst du die Versionsinformation eingeben:

1 Einen XML-Kommentar hinzugefügt.
2 -- Diese und die folgenden Zeilen werden ignoriert --
3
4 M test.xml

Du musst dabei einfach nur die entsprechende Versionsinformation eingeben, abspeichern und den Editor schließen. Nachdem du den Editor geschlossen hast, werden die Änderungen an Subversion übermittelt:

Sende test.xml
Übertrage Daten .
Revision 2 übertragen.

Subversion gibt nach dem Commit also sowohl die neue Revisionsnummer aus als auch die Dateien, die übertragen worden sind.

Weiterführende Informationen

Im O’Reilly-Verlag ist ein Buch über Subversion erschienen, das man sich auf der Buch-Homepage kostenlos als HTML- oder PDF-Version herunterladen kann:In diesem Buch ist auch beschrieben, wie man ein SVN-Repository auf einem Apache-Webserver anlegen kann.