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 Nutzerkonten auf dem Server eingerichtet werden.
Das Passwort wird nicht über das Netzwerk übertragen.
Es gibt standardmäßig nur eine Authentifizierungsmethode, 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.)
Es wird nichts geloggt, auch keine Fehler.
Keinen eingebauten Webbrowser-gestützten Lesezugriff. (Wenn Sie dies wünschen, müssen Sie einen eigenständigen Webserver sowie Repository-Browser-Software installieren.)
Das verwendete Netzwerkprotokoll ist zustandsorientiert und merklich schneller als WebDAV.
Sie können bestehende Nutzerzugänge des SSH-Servers verwenden.
Der gesamte Netzwerkverkehr ist verschlüsselt.
Es steht nur eine Authentifizierungsmöglichkeit zur Verfügung.
Es wird nichts geloggt, auch keine Fehler.
Die verwendeten Nutzer müssen in derselben Nutzergruppe (auf dem Server) sein, oder sich einen SSH-Key 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 Authentifizierungsmethoden (und das sind viele).
Es müssen auf dem Server keine Nutzerkonten angelegt werden.
Apache loggt 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 Repository kann lesend auch via Webbrowser zugegriffen werden.
Das Repository lässt sich als Netzlaufwerk einhängen (mounten). Änderungen an den Dateien unterliegen trotzdem der Versionskontrolle. (siehe „Autoversioning“.)
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 Nutzerbetreuung:
Falls Sie für ihr Team die einfachste Servervariante suchen, dann kommen Sie mit einer Standard-svnserve-Installation am schnellsten ans Ziel. Beachten Sie aber, dass der Inhalt ihres Repositorys im Klartext über das Netzwerk übertragen wird. Wenn Sie nur innerhalb ihres Firmennetzwerks oder eines VPNs arbeiten, so ist dies kein Beinbruch. Ist ihr Repository allerdings vom Internet aus erreichbar, so sollten Sie eventuell sicherstellen, dass darin keine sensiblen Daten vorhanden sind (z.B. nur Open-Source Code o.ä.), oder Sie legen noch einmal Hand an und verschlüsseln mittels SASL die Netzwerkverbindung zur ihrem Repository.
Wenn Sie bereits über Systeme zur Authentifizierung (LDAP, Active Directory, NTLM, X.509 etc.) 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. Stehen serverseitige Logs zur Aufzeichnung von Client-Aktivitäten und Serverfehlern auf Ihrer Wunschliste, dann ist Apache die einzige Option.
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 Repository nur diesem svn-Nutzer gehört. Damit wird der Zugriff auf ihr Repository 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 Repository zu ermöglichen und eben nicht mittels vollwertiger Nutzerzugä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 Repository mittels der
file://-Methode zu geben. Auch wenn der Zugriff
auf das Repository durch eine Netzwerkfreigabe erfolgt, bleibt es immmer
noch eine schlechte Idee.
Dadurch wird jeglicher Sicherheitspuffer zwischen dem Nutzer und dem Repository
entfernt: Ein Anwender kann ohne (oder auch mit) Absicht die Datenbank des Repositorys
beschädigen.
Es wird zudem schwierig, das Repository offline zu nehmen um eine Inspektion
oder ein Upgrade durchzuführen. Zudem kann es Ihnen eine Menge Probleme mit
den Dateirechten einbringen (siehe „Supporting Multiple Repository Access Methods“).
Beachten Sie bitte auch, dass dies einer der Gründe ist, warum wir vor der
Verwendung der svn+ssh://-Methode für den Repository-Zugriff
warnen. Vom Standpunkt der Sicherheit ist dies effektiv dasselbe wie
die Verwendung von file:// für den Zugriff durch lokale
Benutzer und kann zu denselben Problemen führen, wenn der Administrator nicht
alle Vorsicht walten lässt.