DAV steht für „Distributed Authoring and Versioning“ (Verteilte Erstellung und Versionierung). RFC 2518 definiert eine Reihe Konzepte und begleitende Erweiterungsmethoden für HTTP 1.1, die aus dem Web ein universelles Lese- und Schreibmedium machen. Die grundlegende Idee ist, dass ein WebDAV-konformer Web-Server sich wie ein gewöhnlicher Datei-Server verhalten kann; Clients können freigegebene Ordner über HTTP „einhängen“, die sich völlig wie andere vernetzte Dateisysteme verhalten (wie etwa NFS oder SMB).

Das Trauerspiel jedoch ist, dass trotz des Akronyms die RFC-Spezifikation keinerlei Versionskontrolle beschreibt. Einfache WebDAV-Clients und Server gehen davon aus, dass lediglich eine Version jeder Datei oder jedes Verzeichnisses existiert und sie wiederholt überschrieben werden kann.

Da RFC 2518 Versionierungskonzepte ausließ, war einige Jahre später ein anderes Komitee dafür verantwortlich, RFC 3253 zu schreiben. Der neue RFC fügt WebDAV Versionierungskonzepte hinzu und packt das „V“ wieder zurück in „DAV“ – daher der Begriff „DeltaV“. WebDAV/DeltaV-Clients und -Server werden oft nur „DeltaV“-Programme genannt, da DeltaV das Vorhandensein des grundlegenden WebDAV voraussetzt.

Der ursprüngliche WebDAV-Standard war auf breiter Linie erfolgreich. Jedes moderne Betriebssystem verfügt über einen eingebauten WebDAV-Client (Einzelheiten später), und eine Anzahl verbreiteter eigenständiger Anwendungen sprechen ebenfalls WebDAV – Microsoft Office, Dreamweaver und Photoshop, um nur ein paar aufzuzählen. Serverseitig war der Apache HTTP Server in der Lage, seit 1998 WebDAV-Dienste anzubieten und wird als der quelloffene de facto Standard angesehen. Mehrere andere kommerzielle WebDAV-Server sind erhältlich, u.a. IIS von Microsoft.

Leider war DeltaV nicht so erfolgreich. Es ist sehr schwierig, irgendwelche DeltaV-Clients oder -Server zu finden. Die wenigen vorhandenen sind relativ unbekannte kommerzielle Produkte, und somit ist es sehr schwierig, die Interoperabilität zu testen. Es ist noch nicht völlig geklärt, warum DeltaV so stockend voran kam. Manche sind der Meinung, dass die Spezifikation zu komplex sei. Andere wiederum sagen, dass, während sich die Möglichkeiten von WebDAV an die Masse wenden (selbst minder technikaffine Benutzer wissen vernetzte Dateisysteme zu schätzen), seine Versionskontrollfähigkeiten dagegen für die meisten Benutzer nicht interessant oder notwendig seien. Schließlich glauben manche, dass DeltaV unbeliebt bleibe, weil es noch kein quelloffenes Server-Produkt mit einer guten Implementierung gibt.

Als sich Subversion noch in der Entwurfsphase befand, schien es eine großartige Idee zu sein, Apache als einen Netz-Server zu verwenden. Es gab bereits ein Modul, das WebDAV-Dienste anbot. DeltaV war eine relativ neue Spezifikation. Es bestand die Hoffnung, dass sich das Server-Modul von Subversion (mod_dav_svn) schließlich zu einer quelloffenen Referenzimplementierung von DeltaV entwickeln würde. Unglücklicherweise besitzt DeltaV ein sehr spezifisches Versionierungsmodell, das sich nicht ganz mit dem Modell von Subversion deckt. Einige Konzepte ließen sich abbilden, andere nicht.

Was bedeutet das nun?

Zunächst ist der Subversion-Client kein vollständig implementierter DeltaV-Client. Er benötigt bestimmte Dinge vom Server, die DeltaV von sich aus nicht bieten kann, und ist deshalb zu einem großen Teil abhängig von einer Anzahl Subversion-spezifischer HTTP REPORT Anfragen, die nur mod_dav_svn versteht.

Zweitens ist mod_dav_svn kein vollständig umgesetzter DeltaV-Server. Viele Teile der DeltaV-Spezifikation waren für Subversion irrelevant und wurden nicht implementiert.

Eine lang anhaltende Debatte innerhalb der Entwicklergemeinde von Subversion, ob es den Aufwand lohne, irgendeine dieser Situationen zu beheben, wurde letztendlich beigelegt, indem die Subversion-Entwickler offiziell beschlossen, die Pläne zur vollständigen Unterstützung von DeltaV aufzugeben. Neuere Versionen von Subversion werden selbstverständlich weiterhin die bereits in älteren Releases vorhandene DeltaV-Funktionalität unterstützen, jedoch wird keine Arbeit aufgewendet, um die Spezifikation weiter abzudecken; tatsächlich würde Subversion absichtlich beginnen, sich vom strengen DeltaV als sein primäres HTTP-basiertes Protokoll zu entfernen.