Présentation générale

Subversion a été conçu avec une couche réseau abstraite. Cela signifie que l'on peut accéder de façon automatisée à un dépôt par toute sorte de protocoles client/serveur, et que l'interface (l'API) d'accès au dépôt du client permet aux programmeurs d'écrire des greffons implémentant les protocoles réseaux appropriés. En théorie, Subversion peut utiliser un nombre infini d'implémentations réseau. En pratique, il n'existe à ce jour que deux serveurs.

Apache est un serveur web extrêmement populaire ; en utilisant le module mod_dav_svn, Apache a accès au dépôt et peut le rendre accessible aux clients via le protocole WebDAV/DeltaV, qui est une extension d'HTTP. Comme Apache est un serveur très complet, il inclut un grand nombre de fonctionnalités « gratuites », telles que : communications chiffrées par SSL, journalisation, intégration avec bon nombre de systèmes d'authentification tiers et navigation web limitée des dépôts.

À l'opposé vous trouvez svnserve : un petit programme serveur, léger, qui communique via un protocole sur mesure avec les clients. Parce que ce protocole a été conçu spécialement pour Subversion et possède la notion d'états (à la différence d'HTTP), il offre des opérations significativement plus rapides, certes aux dépens de certaines fonctionnalités. Bien qu'il sache utiliser SASL pour offrir toute une gamme d'options d'authentification et de chiffrement, il ne possède ni journalisation ni navigation web intégrée. Il est néanmoins très facile à mettre en place et constitue souvent le meilleur choix pour de petites équipes débutant avec Subversion.

Une troisième option consiste à utiliser svnserve encapsulé dans une connexion SSH. Même si ce scénario utilise toujours svnserve, il diffère quelque peu, en termes de fonctionnalités, d'un déploiement svnserve traditionnel. SSH sert à chiffrer toutes les communications. Par ailleurs, l'authentification utilise exclusivement SSH, ce qui nécessite des comptes utilisateurs au niveau système sur le serveur hôte (à la différence de « svnserve simple », qui possède ses propres comptes utilisateurs privés). Enfin, avec ce type de déploiement, un processus svnserve temporaire privé est créé pour chaque utilisateur qui se connecte, ce qui équivaut (du point de vue des permissions) à permettre à un groupe d'utilisateurs locaux d'accéder au dépôt via des URL file://. Les autorisations d'accès basées sur des chemins n'ont donc aucun sens, puisque chaque utilisateur accède directement aux fichiers de la base de données du dépôt.

Le Tableau 6.1, « Comparaison des fonctionnalités des serveurs Subversion » présente un résumé rapide des trois types courants de déploiements de serveurs.

Tableau 6.1. Comparaison des fonctionnalités des serveurs Subversion

Fonctionnalité Apache + mod_dav_svn svnserve svnserve sur SSH
Authentification Authentification HTTP(S) de base, certificats X.509, LDAP, NTLM, ou tout autre mécanisme compatible avec Apache. CRAM-MD5 par défaut ; LDAP, NTLM, ou tout autre mécanisme compatible avec SASL. SSH.
Comptes utilisateurs Fichiers privés ou tout autre mécanisme compatible avec Apache (LDAP, SQL, etc.). Fichiers privés ou tout autre mécanisme compatible avec SASL (LDAP, SQL, etc.). Comptes utilisateurs systèmes.
Contrôle d'accès L'accès en lecture/écriture peut être autorisé sur le dépôt tout entier ou restreint à des chemins spécifiés. L'accès en lecture/écriture peut être autorisé sur le dépôt tout entier ou restreint à des chemins spécifiés. L'accès en lecture/écriture ne peut être autorisé que sur le dépôt tout entier.
Chiffrement Disponible via SSL (option). Disponible via les fonctionnalités optionnelles de SASL. Inhérent à toute connexion SSH.
Journalisation Journaux Apache complets de chaque requête HTTP et, en option, la journalisation « de haut niveau » des opérations côté client. Pas de journaux. Pas de journaux.
Interopérabilité Accessible par tout client WebDAV. Ne peut communiquer qu'avec des clients svn. Ne peut communiquer qu'avec des clients svn.
Accès via une interface Web Support intégré limité ou via des outils tiers tels que ViewVC. Uniquement via des outils tierces tels que ViewVC. Uniquement via des outils tierces tels que ViewVC.
Réplication serveur de type maître-esclave Possibilité d'un mandataire transparent pour l'écriture (de l'esclave vers le maître). Possibilité de créer seulement des serveurs esclaves en lecture seule. Possibilité de créer seulement des serveurs esclaves en lecture seule.
Vitesse Relativement plus lent. Relativement plus rapide. Relativement plus rapide.
Mise en place Relativement complexe. Extrêmement simple. Moyennement simple.