Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.
Also dann, welchen Server sollten Sie nun verwenden? Welcher ist der beste?
Auf diese Frage gibt es offensichtlich nicht die eine, richtige Antwort. Denn jedes Team stellt andere Anforderungen, und die verschieden Server bieten unterschiedliche Funktionen und Voraussetzungen. Das Subversion-Projekt selbst bevorzugt keinen der genannten Server oder betrachtet einen als etwas „offizieller“ als die anderen.
Wir beleuchten nun die einzelnen Gründe, die für die eine oder andere Konstellation sprechen, ebenso auch Gründe, welche vielleicht gegen eine der Möglichkeiten sprechen.
Das Aufsetzen geht schnell und einfach.
Das verwendete Netzwerkprotokoll ist zustandsorientiert und merklich schneller als WebDAV.
Es müssen keine lokalen Anwenderkonten auf dem Server eingerichtet werden.
Das Passwort wird nicht über das Netzwerk übertragen.
Es gibt standardmäßig nur eine Authentifikationsmethode, das Netzwerkprotokoll ist unverschlüsselt und das Passwort wird vom Server im Klartext gespeichert. (Mit SASL können diese Probleme zwar umgangen werden, dies erfordert aber eine etwas aufwendigere Konfiguration.)
Keine erweiterte Protokollierung.
Keinen eingebauten Web-Browser-gestützten Lesezugriff. (Wenn Sie dies wünschen, müssen Sie einen eigenständigen Webserver sowie Projektarchiv-Browser-Software installieren.)
Das verwendete Netzwerkprotokoll ist zustandsorientiert und merklich schneller als WebDAV.
Sie können bestehende Anwenderzugänge des SSH-Servers verwenden.
Der gesamte Netzwerkverkehr ist verschlüsselt.
Es steht nur eine Authentifikationsmöglichkeit zur Verfügung.
Keine erweiterten Protokollierungsmöglichkeiten.
Die verwendeten Nutzer müssen in derselben Anwendergruppe (auf dem Server) sein, oder sich einen SSH-Schlüssel teilen.
Bei unsachgemäßer Verwendung kann es zu Problemen mit den Dateirechten kommen.
Subversion hat damit Zugriff auf alle für den Apache verfügbaren Authentifikationsmethode (und das sind viele).
Es müssen auf dem Server keine Anwenderkonten angelegt werden.
Apache protokolliert nach Wunsch (fast) alles.
Der Netzwerkverkehr kann mittels SSL verschlüsselt werden.
In der Regel lässt sich das HTTP(S)-Protokoll problemlos durch Firewalls routen.
Auf das Projektarchiv kann lesend auch via Web-Browser zugegriffen werden.
Das Projektarchiv lässt sich als Netzlaufwerk einhängen (mounten). Änderungen an den Dateien unterliegen trotzdem der Versionskontrolle. (siehe „Autoversionierung“.)
Er ist merklich langsamer als svnserve, da HTTP als zustandsloses Protokoll eine höhere Netzwerklast verursacht.
Die Ersteinrichtung kann etwas schwierig sein.
Im Allgemeinen empfehlen die Autoren dieses Buches eine einfache svnserve-Installation für kleine Teams, denen an einer schnellen und unkomplizierten Nutzung von Subversion gelegen ist. Dies ist die Variante, welche sich am einfachsten einrichten und administrieren lässt. Sollte später Bedarf bestehen, so kann immer noch auf eine komplexere Servervariante gewechselt werden.
Es folgen einige allgemeine Empfehlungen und Tipps, basierend auf mehrjähriger Erfahrung in der Anwenderbetreuung:
Falls Sie für ihr Team die einfachste Servervariante suchen, dann kommen Sie mit einer Standard-Installation von svnserve am schnellsten ans Ziel. Beachten Sie aber, dass der Inhalt ihres Projektarchivs im Klartext über das Netzwerk übertragen wird. Wenn Sie nur innerhalb ihres Firmennetzwerks oder eines VPN arbeiten, so ist dies kein Beinbruch. Ist ihr Projektarchiv allerdings vom Internet aus erreichbar, so sollten Sie eventuell sicherstellen, dass darin keine sensiblen Daten vorhanden sind (z.B., nur quelloffenen Code o.ä.), oder Sie legen noch einmal Hand an und verschlüsseln mittels SASL die Netzwerkverbindung zur ihrem Projektarchiv.
Wenn Sie bereits über Systeme zur Authentifikation (LDAP, Active Directory, NTLM, X.509 usw.) verfügen und Subversion in diese integrieren möchten, so bleibt Ihnen die Wahl zwischen einer Apache-gestützten Variante oder eines mit SASL vermählten svnserve.
Wenn Sie sich für die Verwendung von Apache oder eines Standard-svnserve entschieden haben, dann legen Sie auf ihrem System einen einfachen svn-Nutzer an und lassen den Serverprozess unter diesem Nutzer laufen. Stellen Sie zudem sicher, dass das gesamte Verzeichnis mit dem Projektarchiv nur diesem svn-Nutzer gehört. Damit wird der Zugriff auf ihr Projektarchiv durch das Dateisystem des Serverbetriebssystems verwaltet, und nur der Serverprozess kann noch Änderungen daran vornehmen.
Wenn Sie bereits über eine aus SSH-Zugängen bestehende Infrastruktur verfügen, und Ihre Nutzer auf dem Subversion-Server schon lokale Zugänge haben, dann ist die Verwendung einer svnserve-über-SSH-Lösung sinnvoll. Wir empfehlen diese Variante allerdings nur sehr ungern. Es ist im Allgemeinen sicherer, Ihren Nutzern nur durch svnserve oder Apache verwaltete Zugänge den Zugriff auf Ihr Projektarchiv zu ermöglichen und eben nicht mittels vollwertiger Anwenderzugänge auf dem Serversystem. Falls der Wunsch nach einer starken Netzwerkverschlüsselung Sie auf die Verwendung des SSH gebracht hat, dann empfehlen wir Ihnen stattdessen die Verwendung von Apache und SSL, bzw. die Kombination aus svnserve und SASL-Verschlüsselung.
Lassen Sie sich bitte nicht von
der Idee verführen, allen Ihren Nutzern direkten Zugriff
auf das Projektarchiv mittels der
file://-Methode zu geben. Auch wenn
der Zugriff auf das Projektarchiv durch eine
Netzwerkfreigabe erfolgt, bleibt es immer noch eine
schlechte Idee. Dadurch wird jeglicher Sicherheitspuffer
zwischen dem Nutzer und dem Projektarchiv entfernt: Ein
Anwender kann ohne (oder auch mit) Absicht die Datenbank
des Projektarchivs beschädigen. Es wird zudem schwierig,
das Projektarchiv offline zu nehmen um eine Inspektion
oder ein Upgrade durchzuführen. Zudem kann es Ihnen eine
Menge Probleme mit den Dateirechten einbringen (siehe
„Unterstützung mehrerer Zugriffsmethoden auf das Projektarchiv“). Beachten
Sie bitte auch, dass dies einer der Gründe ist, warum wir
vor der Verwendung der
svn+ssh://-Methode für den
Projektarchiv-Zugriff warnen. Vom Standpunkt der
Sicherheit ist dies effektiv dasselbe wie die Verwendung
von file:// für den Zugriff durch
lokale Anwender und kann zu denselben Problemen führen,
wenn der Administrator nicht alle Vorsicht walten lässt.