DAV signifie Distributed Authoring and Versioning, que l'on pourrait traduire par « Écriture distribuée et gestion de versions ». La RFC 2518 définit un ensemble de concepts et d'extensions sur la base du protocole HTTP 1.1 afin de faire du Web un support de lecture/écriture plus universel. L'idée est qu'un serveur Web compatible WebDAV peut être considéré comme un serveur de fichiers générique ; les clients peuvent « monter » des répertoires partagés, au-dessus d'une couche HTTP, et ces répertoires se comportent pratiquement comme les autres systèmes de fichiers en réseau (tels que NFS ou SMB).

Là où le bât blesse, c'est que, malgré l'acronyme, les spécifications de la RFC ne décrivent en fait aucun façon d'assurer la gestion de versions. Les clients et serveurs WebDAV de base considèrent que chaque fichier ou répertoire n'existe qu'en une seule version, qui peut être ré-écrite autant de fois que l'on veut.

Comme la RFC 2518 a ignoré les concepts de gestion de versions, un autre groupe de travail a hérité de la responsabilité d'écrire la RFC 3253 quelques années plus tard. La nouvelle RFC ajoute le concept de gestion de versions à WebDAV, en rendant sa signification au « V » de « DAV », d'où le terme « DeltaV ». Les clients et serveurs WebDAV/DeltaV sont souvent appelés « DeltaV » tout court, puisque DeltaV implique obligatoirement la prise en compte de WebDAV.

Le standard WebDAV initial a connu un grand succès. Tous les systèmes d'exploitation modernes ont un client WebDAV intégré (nous les abordons en détail plus tard) et de nombreux logiciels sont également capables de communiquer via ce protocole :Microsoft Office, Dreamweaver, Photoshop pour n'en citer que quelques uns. Côté serveur, le serveur HTTP Apache dispose de services WebDAV depuis 1998 et est considéré de facto comme la référence en matière de logiciel libre. Il existe plusieurs autres serveurs WebDAV commerciaux, dont le propre serveur de Microsoft, IIS.

Malheureusement, DeltaV n'a pas connu un grand succès. Il est très difficile de trouver des clients ou des serveurs DeltaV. Les rares qui existent sont des serveurs commerciaux plus ou moins inconnus ; l'interopérabilité est donc très difficile à tester. Il n'est pas évident de trouver pourquoi DeltaV n'a pas percé. Certains mettent en cause des spécifications trop complexes. D'autres arguent du fait que, contrairement à WebDAV, qui est une technologie de masse (même les utilisateurs les moins férus d'informatique aiment partager des fichiers en réseau), ses fonctionnalités de gestion de versions intéressent peu ou ne sont pas nécessaires à la majorité des gens. Enfin, certains sont persuadés que DeltaV n'intéresse pas grand monde parce qu'il n'existe aucun serveur libre qui l'implémente correctement.

Quand Subversion était encore en phase de conception, l'utilisation d'Apache comme serveur réseau paraissait une très bonne idée. Il possédait déjà un module pour fournir des services WebDAV et DeltaV était une spécification relativement jeune. L'idée était que le module serveur de Subversion (mod_dav_svn) évoluerait pour devenir l'implémentation libre de référence de DeltaV. Malheureusement, DeltaV possède un modèle de gestion de versions très particulier, qui n'est pas vraiment compatible avec le modèle de Subversion. Certains concepts pouvaient être adaptés, mais d'autres non.

Quelles conséquences en tirer ?

Premièrement, le client Subversion n'est pas un client DeltaV complet. Il a besoin d'informations de la part du serveur que DeltaV est incapable de lui fournir, ce qui implique qu'il dépend en grande partie de requêtes HTTP REPORT spécifiques à Subversion que seul mod_dav_svn sait interpréter.

Deuxièmement, mod_dav_svn n'implémente pas toutes les fonctionnalités d'un serveur DeltaV. De nombreux éléments des spécifications du protocole DeltaV ne sont pas pertinents dans le cas de Subversion et n'ont donc pas été implémentés.

Savoir si cela valait la peine de combler ces lacunes a fait l'objet d'un long débat au sein de la communauté des développeurs Subversion. La communauté a finalement officiellement décidé d'abandonner le support complet de DeltaV. Depuis Subversion 1.7, le client et le serveur implémentent plusieurs simplifications « hors clous » du standard DeltaV^[85] et il est probable que d'autres adaptations de ce genre suivent. Ces versions de Subversion continueront à offrir une compatibilité avec les anciennes versions, mais aucun travail ne sera fait pour améliorer la couverture des spécifications (Subversion s'écarte délibérément du DeltaV strict comme protocole HTTP de base).