HowTo zum Aufsetzen und Benutzen eines SVN Servers

1. Einrichten und Konfigurieren des Servers

Zum Zugriff auf die Subversion Repositories können verschiedene Server verwendet werden, Apache mit WebDAV oder svnserve. Bei svnserve hat man die Wahl, ob svnserve als standalone Server laufen soll, in Verbindung mit ssh oder über inetd.
Im folgenden wird der nur der Fall svnserve mit inetd betrachtet.
Um dem Serverprozess nicht unnötig viele Rechte zu geben, werden ein User und eine Gruppe 'svn' benötigt, unter denen der Server gestartet wird und dem die Repositories gehören.

1.1. Konfiguration von inetd

Folgende Zeile in inetd.conf wird verwendet:

svn stream tcp nowait svn.svn /usr/bin/svnserve svnserve -i -r /pfad/zu/den/Repositories

Das erste 'svn' gibt den Service an und muss in /etc/services definiert sein. Der Port für Subversion ist 3690. In der fünften Spalte wird der Benutzer und die Gruppe angegeben mit der das Programm in aus der sechsten Spalte gestartet werden soll. Die Parameter von svnserve:
-i: startet svnserve im inetd Modus
-r: legt das Root Verzeichnis der Repositories fest. Ein Zugriff auf Dateien in höheren Verzeichnisebenen ist somit nicht mehr möglich.

1.2. Anlegen der Repositories

Bevor man auf ein Repository zugreifen kann, muss dieses lokal auf dem Server erstellt werden. Dies geschiet mit dem Befehl svnadmin:

$ svnadmin create /pfad/zu/dem/Repository
z.B. svnadmin create /opt/svn/lughp

Der Pfad muss dabei unterhalb des Pfades liegen, der svnserve mit dem Parameter '-r' übergeben wurde. Ansonsten kann nicht darauf zugegriffen werden. Ausserdem müssen die Rechte des Repositories noch auf den Benutzer und die Gruppe svn geändert werden, da svnserve diese ansonsten evtl. nicht lesen darf.

1.3. Konfiguration der Repositories

Für jedes Repository können getrennt die Zugriffsberechtigungen konfiguriert werden. Die Konfiguration dazu liegt im Unterverzeichnis 'conf' des Repositories.

Aufbau der Datei svnserve.conf:

[general]
anon-access = [none, read, write]
auth-access = [none, read, write]
password-db = [Dateiname]

'anon-access' legt fest, welche Operation ohne Anmeldung erlaubt sind. (keine, nur lesen oder Vollzugriff)
'auth-access' ist dasselbe für die angemeldeten Benutzer.
'password-db' legt die Datei fest, in der die Usernamen und Passwörter für die Anmeldung gespeicher sind.

Aufbau der Passwort Datei:

[users]
username = passwort
...

1.4. URL für ein Repository

Die URL zum Zugriff auf die Repositories sieht wie folgt aus:

svn://name.des.servers/pfad/zum/repository
z.B. svn://lug-untermain.de/lughp

Der Pfad ist dabei relativ zu dem Pfad, der in der inetd.conf angegeben wurde.

Beispiel:
Name des Servers: svn.domain.tld
inetd.conf:
[...] svnserve -i -r /opt/svn
Repository in /opt/svn/projekt
URL für den Zugriff: svn://svn.domain.tld/projekt

2. Verwendung eines Repositories

In einem Repository werden alle alten Version der verwalteten Dateien aufbewahrt und können immer wieder hergestellt werden. Daher kann nicht direkt mit dem Repository gearbeitet werden, sondern jeder Entwickler braucht eine eigene Arbeitskopie in der die eigentliche Arbeit vorgenommen wird. Die eigenen Änderungen sollten immer in logisch zusammenhängenden Teilen an das Repository übertragen (commit) werden.

Die im folgenden angegeben Befehle werden immer im Wurzelverzeichnis der eigenen Arbeitskopie ausgeführt.

2.1. Importieren vorhander Dateien

Um ein bestehendes Projekt in ein neues, leeres Repository einzufügen, kann der Befehl import verwendet werden:

$ svn import Pfad URL
z.B. svn import /tmp/html svn://lug-untermain.de/lughp

Pfad: Verzeichnis in dem das Projekt liegt
URL: Adresse des Repositories in dem das Projekt gespeichert werden soll.

2.2. Erstellen der Arbeitskopie

Um mit der eigentlich Arbeit beginnen zu können muss zu erst eine Arbeitskopie des Repositories erstellt werden. Hierzu dient der Subversion Befehl 'checkout' (oder in kurz: 'co'):

$ svn checkout URL [Pfad]
oder:
$ svn co URL [Pfad]

z.B. svn co svn://lug-untermain.de/lughp /home/tux/html

URL: Adresse des Repositories
Pfad: diese Angabe ist Optional und gibt an wo die Arbeitskopie abgelegt werden soll. Wird diese Angabe weggelassen wird der letzte Teil der URL verwendet.

2.3. grundlegender Arbeitszyklus

Wenn eine Arbeitskopie erstellt wurde sieht der weiter Arbeitsablauf wie folgt aus:

• Aktualisieren der Arbeitskopie
• Vornehmen eigener Änderungen
• Überprüfen der Änderungen
• Beheben von Konflikten
• Übertragen der Änderungen

2.3.1. Aktualisieren der Arbeitskopie

Um die Änderungen im Repository in die eigene Arbeitskopie zu übernehmen, wird diese mit dem Befehl 'update' auf den neusten Stand gebracht.

$ svn update

Wenn dabei lokale Änderungen vorhanden sind, werden diese, soweit möglich, automatisch mit den Änderungen aus dem Repository kombiniert. Ist dieser Vorgang nicht automatisch möglich liegt ein sogenannter Konflikt vor, der manuell behoben werden muss. Dazu aber später mehr.

2.3.2. Vornehmen eigener Änderungen

Alle Dateien können normal editiert werden und diese Änderungen werden von Subversion automatisch erkannt. Sollen hingegen neue Dateien hinzugefügt werden, wird diese zuerst normal erstellt, aber anschliessend muss man Subversion mitteilen, dass diese Datei auch verwaltet werden soll. Hierzu dient der Befehl 'add'.

$ svn add Datei|Pfad

Neue Verzeichnisse werden mit dem Befehl 'mkdir' erstellt.

$ svn mkdir Pfad

Löschen geht ebenfalls nur über Subversion, ansonsten wird die Datei beim nächsten update wieder hergestellt.

$ svn remove Datei|Pfad

Sollen Dateien kopiert oder verschoben werden, sollten auch die Subversion Befehle hierzu verwendet werden, da ansonsten die History der Dateien verloren gehen.

$ svn copy Quelle Ziel
$ svn move Quelle Ziel

Alle Änderungen durch diese Befehle wirken sich sofort auf die Arbeitskopie aus, werden aber erst beim nächsten 'commit' an das Repository übertragen.

2.3.3. Überprüfen der Änderungen

Die Änderungen an der Arbeitskopie lassen sich mit dem Befehl 'status' anzeigen.

$ svn status

Die Ausgabe listet alle Dateien und Verzeichnisse auf, die geändert, neu hinzugefügt oder gelöscht worden sind. Alle diese Änderungen werden bei einem 'commit' an das Repository übertragen. Sollen Änderungen an einer Datei rückgängig gemacht werden, kann der Befehl 'revert' verwendet werden.

$ svn revert Datei

Dies stellt die Datei wieder mit dem ürsprünglichen Inhalt her. Alle lokalen Änderungen sind verloren.

2.3.4. Beheben von Konflikten

Ist beim 'update' ein Konflikt aufgetreten, muss dieser erst behoben werden bevor ein 'commit' möglich ist. Von der Datei, die den Konflikt erzeugt liegen 4 Version in der Arbeitskopie vor:
Datei.rOLDREV, Datei.rNEWREV, Datei.mine, Datei
Datei.rX ist die Datei aus der jeweiligen Repository Revision X.
Datei.mine ist die Version, wie sie vor dem update war.
In 'Datei' sind die widersprüchlicen Änderungen mit Konfliktmarkern hervorgehoben. Zwischen dem jeweils ersten und zweiten Konfliktmarker ist ihre Version und zwischen dem zweiten und dritten die widersprüchliche Version aus dem Repository. Alle Stellen, an denen sich diese Konfliktmarker befinden, müssen bearbeitet und die Konflikte behoben werden. Dabei müssen auch die Konfliktmarker gelöscht werden (diese sollen ja schliesslich nicht in der Datei erhalten bleiben). Ist dies geschehen können die anderen drei Dateien (mit .rx und .mine) gelöscht werden. Durch das löschen der Dateien wird Subversion mitgeteilt, das der Konflikt behoben ist.

2.3.5. Übertragen der Änderungen

Sind alle Konflikte behoben können die lokalen Änderungen mit 'commit' an das Repository übertragen werden. Jeder commit kann mit einem Logeintrag dokumentiert werden, damit die anderen Entwickler schnell sehen, was in diesem commit enthalten ist.

$ svn commit -m "Log Meldung" [Dateien]

Wird der Parameter mit den Dateien weggelassen, werden alle Änderungen, die im aktuellen Verzeichnis und dessen Unterverzeichnis sind, übertragen. Ansonsten nur die Änderungen an den angegeben Dateien.

3. weitere Quellen zu Subversion

[1] Das freie Subversion Buch: http://svnbook.red-bean.com

Klaus Flittner