Et alors, quel serveur vous faut-il ? Quel est le meilleur ?
Bien évidemment, il n'y a pas de bonne réponse à cette question. Chaque équipe a des besoins propres et les différents serveurs représentent des compromis différents. Le projet Subversion lui-même ne recommande pas un serveur plus qu'un autre, ni ne considère qu'un serveur est plus « officiel » qu'un autre.
Voici quelques argumentaires qui vous aideront à choisir entre un déploiement et un autre, ainsi que quelques raisons de ne pas choisir l'un d'entre eux.
facile et rapide à mettre en place ;
le protocole réseau possède la notion d'états et est significativement plus rapide que WebDAV ;
pas besoin de créer des comptes utilisateurs système sur le serveur ;
le mot de passe ne circule pas sur le réseau.
par défaut, seule une méthode d'authentification est disponible, le protocole réseau n'est pas chiffré et le serveur enregistre les mots de passe en clair (tous ces éléments peuvent être modifiés en configurant SASL, mais cela requiert un peu plus de travail) ;
aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni même celle des erreurs ;
pas de navigation web intégrée (il vous faut installer un serveur web séparé et un logiciel de navigation du dépôt pour ajouter cette fonctionnalité).
le protocole réseau possède la notion d'états et est significativement plus rapide que WebDAV ;
vous pouvez tirer parti des comptes SSH existants et de l'infrastructure déjà mise en place pour les utilisateurs ;
tout le trafic réseau est chiffré.
il n'y a qu'un seul choix possible de méthode d'authentification ;
aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni même celle des erreurs ;
les utilisateurs doivent être membres du même groupe système ou utiliser une clé SSH partagée ;
mal utilisé, il peut aboutir à des problèmes de droits sur les fichiers.
il permet à Subversion d'utiliser n'importe lequel des nombreux systèmes d'authentification déjà intégrés dans Apache ;
pas besoin de créer des comptes système sur le serveur ;
journalisation Apache complète disponible ;
le trafic réseau peut être chiffré par SSL ;
HTTP(S) fonctionne généralement même derrière des pare-feu d'entreprise ;
la possibilité de parcourir le dépôt avec un navigateur Web est disponible nativement ;
le dépôt peut être monté en tant que lecteur réseau à des fins de gestion de versions transparente (voir la section intitulée « Gestion de versions automatique »).
significativement plus lent que svnserve, car HTTP est un protocole sans état et nécessite plus d'allers et retours réseau ;
la mise en place initiale peut s'avérer complexe.
En général, les auteurs de ce livre recommandent une installation ordinaire de svnserve aux petites équipes qui débutent avec Subversion ; c'est le plus simple à installer et celui qui pose le moins de problèmes de maintenance. Vous pouvez toujours passer au déploiement d'un serveur plus complexe au fur et à mesure que vos besoins évoluent.
Voici quelques recommandations et astuces générales, basées sur des années de support aux utilisateurs :
si vous essayez de mettre en place le serveur le plus simple possible pour votre groupe, une installation ordinaire de svnserve est la voie la plus sûre et la plus rapide. Notez cependant que les données de votre dépôt circuleront en clair sur le réseau. Si votre déploiement se situe entièrement à l'intérieur du LAN ou du VPN de votre compagnie, ce n'est pas un problème. Si le dépôt est accessible sur Internet, il serait bon de vous assurer que son contenu n'est pas sensible (c'est-à-dire qu'il ne contient que du code open source), ou alors de faire l'effort supplémentaire de configurer SASL pour chiffrer les communications réseau ;
si vous devez vous insérer au sein de systèmes d'authentification déjà en place (LDAP, Active Directory, NTLM, X.509, etc.), il vous faudra utiliser soit le serveur basé sur Apache, soit svnserve configuré avec SASL. Si vous avez un besoin absolu de journaux des erreurs côté serveur ou de journaux des activités côté client, le serveur basé sur Apache est le seul choix possible ;
que vous ayez décidé d'utiliser Apache ou un banal
svnserve, créez un utilisateur
svn unique sur votre système et
utilisez-le pour faire tourner le processus serveur.
Assurez-vous également que la totalité du répertoire du dépôt
est la propriété de cet utilisateur. Du point de vue de la
sécurité, les données du dépôt restent ainsi englobées et
protégées par l'application des droits gérés par le système
de fichiers du système d'exploitation et sont modifiables
uniquement par le processus serveur Subversion
lui-même ;
si vous avez une infrastructure existante basée principalement sur des comptes SSH et si vos utilisateurs possèdent déjà des comptes système sur la machine qui sert de serveur, il est logique de déployer une solution svnserve sur SSH. Dans le cas contraire, nous ne recommandons généralement pas cette option au public. Il est considéré comme plus sûr de donner l'accès au dépôt à vos utilisateurs au moyen de comptes (imaginaires) gérés par svnserve ou Apache plutôt que par de véritables comptes système. Si vous voulez vraiment chiffrer les communications, nous vous recommandons d'utiliser Apache avec chiffrement SSL ou svnserve avec chiffrement SASL à la place ;
ne vous laissez pas séduire par l'idée très simple de
donner l'accès à un dépôt à tous vos utilisateurs
directement via des URL file://. Même si
le dépôt est accessible à tous sur un lecteur réseau, c'est
une mauvaise idée. Elle ôte toutes les couches de protection
entre les utilisateurs et le dépôt : les utilisateurs
peuvent corrompre accidentellement (ou intentionnellement)
la base de données du dépôt, il est difficile de mettre
le dépôt hors ligne pour inspection ou pour mise à niveau et
vous risquez d'aboutir à de graves problèmes de droits sur
les fichiers (voir la section intitulée « Accès au dépôt par plusieurs méthodes »). Remarquez que
c'est aussi une des raisons pour laquelle nous déconseillons
d'accéder aux dépôts via des URL
svn+ssh:// : du point de vue de la
sécurité, c'est en fait comme si les utilisateurs locaux y
accédaient via file://, ce qui peut
entraîner exactement les mêmes problèmes si l'administrateur
ne fait pas preuve de prudence.