Einrichtung eines SVN-Spiegelservers

Der Subversion-Server des Kunden ist der langsamste seiner Art. Das sorgt für Frust; nicht nur blickt man in Eclipse oft minutenlang auf „Pending…“, wenn man Teilbäume aufklappen möchte, es schlagen auch Hudson-Builds fehl, weil svn update nicht durchgelaufen ist.

Für Hudson könnte man sich behelfen, indem man mit svnsync eine lokale (readonly-)Kopie des Repositories einrichtete, aber in der Entwicklungsumgebung hilft das nicht weiter. Seit Subversion 1.5 ist es zum Glück möglich, das dav_svn-Modul im Apache so zu konfigurieren, dass schreibende Zugriffe direkt auf ein zentrales Repository (den Master) umgeleitet werden während lesende Operationen auf einer lokalen Kopie ausgeführt werden.

Die im Netz zu diesem Thema zu findenden Anleitungen gehen größtenteils davon aus, dass man Master- und Slaveserver unter seiner eigenen Kontrolle hat. Wir können aber am Master nichts konfigurieren und werden deshalb eine etwas sparsamere Variante einrichten müssen.

Voraussetzungen:

• Apache (min. 2.2)
• svn (min. 1.5)
• Apache mod_dav_svn und mod_proxy (sowie Module, von denen die jeweils abhängen)
• Apache mod_ssl (wenn das Master-Repository per https erreichbar ist)

Schritt 0:

Benutzer anlegen (nennen wir ihn mal svnsync), mit dessen Account später die Synchronisation laufen wird. Weil der sich den Zugriff auf das Repository mit dem Webserver teilen wird, habe ich ihn in einer gemeinsamen Gruppe angelegt.

Schritt 1:

Repository anlegen (als root):

svnadmin create /var/www/svn/projekt

Die einzelnen Benutzer müssen wir nicht anlegen, weil das Benutzermanagement und die Commitrechte weiterhin vom Masterserver verwaltet werden.

Schritt 2:

Schreibenden Zugriff aufs Repository für alle Benutzer außer svnsync verbieten. Das geht mit einem „pre-revprop-change“-hook:

#!/bin/sh
USER="$3"

if [ "$USER" != "svnsync" ]; then
    echo >&2 "Only the svnsync user can change revprops"
    exit 1
fi

exit 0

Schritt 3:

Synchronisation starten:

Als Benutzer svnsync muss man die Synchronisationsverbindung erst erstellen (init) und dann die erste Synchronisation durchführen (sync). Je nachdem, wieviele Revisionen es im Master-Repository schon gibt kann das seine Zeit dauern.

 svnsync init file:///var/www/svn/projekt https://subversion.kunde.de/svn/projekt
 svnsync sync file:///var/www/svn/projekt

Passwörter für das Master-Repository müssen in dieser Phase eventuell eingegeben werden und werden dann im Home-Verzeichnis des Synchronisationsbenutzers im .svn-Verzeichnis gespeichert — das ist also mit der notwendigen Vorsicht/Sicherheit zu behandeln.Ständige Synchronisation einrichten:

Da uns, wie gesagt, das Master-Repository nicht gehört, können wir es nicht dazu bringen, uns von Änderungen zu unterrichten. Den sync-Befehl lassen wir deshalb von cron einmal pro Minute ausführen:

* * * * * svnsync sync file:///var/www/svn/projekt > /dev/null 2>&1

Schritt 4:

Zugriff über Apache einrichten:

In schmerzhaften Versuchen musste ich feststellen, dass der Zugriff über den Spiegel nur dann zuverlässig funktioniert, wenn sich die beiden Server möglichst ähnlich sind. Mit verschiedenen Repository-URLs (also wenn der „Verzeichnisname“ des Spiegels sich vom Original unterschied) hatte ich z.T. seltsame Fehlermeldungen („405 Unsupported Operation“,…). Auch der Wechsel von https (auf dem Kundenserver) auf http sorgt für unerklärliches Verhalten bei Verschiebe- und Umbenennoperationen. Wenn das Master-Repository über https erreichbar ist, benötigt man aber ohnehin mod_ssl (und muss den Parameter „SSLProxyEngine“ auf „on“ stellen).

Module laden (dies ist der Mindestumfang, und die Syntax unterscheidet sich je nach Linux/Apache-Distribution):

LoadModule dav_svn_module mod_dav_svn.so
LoadModule proxy_module mod_proxy.so
LoadModule proxy_http_module mod_proxy_http.so
LoadModule ssl_module mod_ssl.so

Konfiguration (Schnipsel an für diesen Apache geeignete Stelle einfügen):

SSLProxyEngine on

<Location /svn/projekt>
    DAV svn
    SVNPath /var/www/svn/projekt
    SVNMasterURI https://subversion.kunde.de/svn/projekt
</Location>

Jetzt kann man mit dem schnellen lokalen Server statt mit der weit entfernten lahmen Ente arbeiten (aber Achtung: nur per http(s) zugreifen, sonst entsteht Chaos!).