SVN steht für Subversion. SVN ist ein Versionskontrollsystem. Es bietet Kontrolle über unterschiedliche Versionszustände von Dateien. Dazu wird zentral auf einem SVN Server der Zustand einer Datei und alle Änderungen, die an der Datei gemacht wurden gespeichert. Dabei werden der Zustand mehrerer Dateien im Verbund festgehalten, damit Abhängigkeiten von Dateien untereinander berücksichtigt werden können.

Anders ausgedrückt: Ändert sich die Version einer Datei, ändert sich ebenso die Version aller anderen Dateien des Projektes. Das Projekt und die Dateien, die darin enthalten sind, werden in dem so genannten Repository gespeichert. Für das gesamte Repository gibt es einen aktuellen Zustand, Revision genannt. Die Revisionsnummer gibt an, welcher Zustand das ist.

Direkt nach dem Anlegen erhält das Repository die Revisionsnummer 0. Nach dem Hinzufügen einer Datei oder eines Ordners ändert sich die Revisionsnummer auf 1. Wird eine weitere Änderung durchgeführt hat das Repository die Revision 2.

Da man Dateien nicht direkt auf dem Server ändern kann, werden sie aus dem Repository auf den lokalen Computer kopiert. Diese Kopie nennt man Arbeitskopie oder "working copy" (kurz: wc). In der Arbeitskopie lassen sich Änderungen durchführen und anschließend am Server bekannt machen. Das Bekanntmachen überträgt den aktuellen Zustand der Datei an den SVN Server bzw. das Repository.

Das Anlegen einer Arbeitskopie nennt man auschecken, das Übertragen der Änderungen  einchecken.

Beim Einchecken von Änderungen wird eine Nachricht eingegeben, die so genannte Commit Message. Diese beschreibt den Grund der Änderungen. Anhand der Commit Messages lässt sich in der Historie nachvollziehen, in wie fern sich das Repository verändert hat.

Es ist möglich, beliebig viele Arbeitskopien anzulegen. Um Änderungen, die im Repository eingecheckt wurden auf die lokale Arbeitskopie zu übertragen, wird ein so genanntes Update gemacht. Durch dieses Update werden alle Änderungen in die lokale Arbeitskopie übertragen.

Versionskontrolle macht Sinn, wenn man allein an einem Projekt arbeitet. Somit stellt man sicher, dass Änderungen verfolgen und seinen Entwicklungsstand jederzeit wieder herstellen zu können. Noch mehr Sinn macht es allerdings, wenn mehrere Entwickler beteiligt sind. So können unterschiedliche Entwicklungen untereinander ausgetauscht und manuelles und fehlerträchtiges Kopieren von Dateien verhindert werden.

Um den Arbeitsablauf zu konkretisieren, ist hier ein ein typischer Anwendungsfall für die Arbeit mit Subversion dragestellt:

$ svn co http://svn2.assembla.com/svn/cakebase/test cakebase

Erstellt eine Arbeitskopie des Projektes Cakebase im Ordner "cakebase"

Um mit Subversion arbeiten zu können, benötigt man einen Subversion Server. Es gibt im Internet kostenlose Dienste, die Subversion services anbieten. Unsere Empfehlung: Subversion Hosting auf assembla.com (affiliate link).

Eine Datei wird angelegt, der Status der Arbeitskopie wird geprüft und anschließend die Datei dem commit hinzugefügt. Der Commit mit der Commit-Message übermittelt die Datei dann ins Repository.

Nach dem Checkin würde der andere Entwickler in seiner Arbeitskopie mittels svn up den aktuellen Code erhalten.

Erweiterte Grundlagen

Subversion bietet mehr als die reine Verwaltung von Dateiinhalten. Es erlaubt die Entwicklung neuer Funktionen, parallel zur Hauptentwicklung. Diese Entwicklungen laufen in etwa folgendermaßen ab: Der Entwickler kopiert den aktuellen Entwicklungsstand in einen neuen Zweig. Dieser Zweig - Im Fachbegriff Branch (oder Feature-Branch) ist eine exakte Kopie des aktuellen Entwicklungsstandes.

Die Weiterentwicklung einer neuen Funktion, findet dann in diesem Zweig statt. Dadurch wird der Inhalt des Haupt Repositories (Trunk genannt) nicht beeinflusst. Im Trunk kann ganz normal weiter gearbeitet werden, also Checkins und Checkous gemacht werden. Die Entwicklung im Branch ist hiervon unabhängig und unberührt. Ein Commit im Trunk ist also nicht automatisch im Branch zu finden. Es liegt also in der Verantwortung des Entwicklers, der den Branch führt, die Commits aus dem Trunk in den Branch mit zu übernehmen.

Da der Entwickler des Branches an einer eigenen Kopie arbeitet, kann er nun an Dingen arbeiten, die umfrangreiche Änderungen erfordern. Die Arbeit der anderen Entwickler aus dem Trunk ist dadurch nicht gestört. Wenn der Feature Branch fertig entwickelt ist, werden die Änderungen in den Trunk übernommen (gemerged).

Per Konvetion gibt es deshalb in einem SVN Repository zumeist folgende Ordner:

• /trunk
• /branches
• /tags

Der Trunk ist immer der aktuellste Entwicklungsstrang.

Unterhalb von Branches werden Ordner angelegt, die dem Zweck der Entwicklung einen Namen geben. Sie werden durch das Kopieren des /trunk Ordners zu einer bestimmten Revision erreicht. Das könnte zum Beispiel so aussehen:

svn cp /trunk /branches/i18n

Anschließend checkt man den Ordner /branches/i18n aus und entwickelt in diesem Pfad weiter.

Tags sind technisch identisch mit Branches. Sie sind eine Kopie von einem anderen Pfad (zu einer bestimmten Revision). Allerdings wird per Konvention ein Tag nicht nachträglich verändert. Vielmehr markiert es einen bestimmten Entwicklungsstand mit einem Namen. Dies macht es möglich, zu dem gemerkten Stand einfach zurück zu kommen.

Für gewöhnlich wird ein Tag dann erstellt, wenn ein bestimmter Punkt im Projekt erreicht ist, wie zum Beispiel das Erreichen eines Meilensteines oder wenn eine Installation auf dem Produktsserver durchgeführt wird.

Wenn dann später in der Produktionsumgebung ein Fehler auftritt, der im /trunk nicht mehr nachvollzogen werden kann (zum Beispiel weil weitere Checkings diesen bereits gefixt haben) ist es möglich, anhand des Tags eine genaue Kopie des Standes zu erhalten, der in Produktion aktiv ist. Das erleichtert die Fehlersuche und erlaubt eine genaue Kontrolle der Änderungen von Version zu Version.