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 périphérique 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 verrons 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 autant de 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.
Le débat est toujours d'actualité au sein de la communauté des développeurs pour savoir si cela vaut la peine de combler ces lacunes. Il serait irréaliste de modifier l'architecture de Subversion pour rallier celle de DeltaV, et donc le client ne sera sans doute jamais capable d'obtenir toutes les informations nécessaires d'un serveur DeltaV. D'un autre côté, mod_dav_svn pourrait être complété pour intégrer les fonctionnalités manquantes de DeltaV, mais il est difficile de se motiver pour le faire : il n'existe pratiquement aucun client DeltaV avec qui communiquer.