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.