DAV 的意思是 “Distributed Authoring and Versioning”。RFC 2518 为 HTTP 1.1 定义了一组概念和附加的扩展方法来把 web 变成一个更加普遍的读/写媒体。基本思想是一个 WebDAV 兼容的 web 服务器可以像普通的文件服务器一样工作；客户端可以通过 HTTP 加载(类似于 NFS 或 SMB) WebDAV 共享文件夹。

悲惨的是，RFC 规范并没有提供任何版本控制模型。基本的 DAV 客户端和服务器只是假定每个文件或目录只有一个版本存在，可以重复的覆盖。

因为 RFC 2518 遗漏了版本概念，几年之后，另一个委员会负责撰写 RFC 3253。新的 RFC 为 WebDAV 增加了版本概念，将 “V” 加入 “DAV”—也就是“DeltaV”。WebDAV/DeltaV 客户端和服务器经常叫做 “DeltaV”客户端和服务器，因为 DeltaV 包含了基本的 WebDAV。

最初的 WebDAV 标准得到了广泛的成功，所有的现代操作系统拥有内置的(后面有详细资料)对普通 WebDAV 的支持，许多流行的应用程序也可以使用 WebDAV—仅举几例，如 Microsoft Office，Dreamweaver 和 Photoshop。在服务器方面，Apache 从 1998 年就开始支持 WebDAV，并被认为是一个事实上的开源标准。也有几个商业的 WebDAV 服务器，例如 Microsoft 自己的 IIS。

不幸的是，DeltaV 没有这样的成功，很难寻找到任何 DeltaV 客户端和服务器。只有一些不太出名的商业产品，因此很难测试交互性。不清楚为什么 DeltaV 这样停滞。一些人说规范太复杂了，还有些人认为尽管 DeltaV 的特性有很大的吸引力(即使最新的技术用户也喜欢使用网络文件共享)，版本控制特性对大多数用户还不是这样有趣和必要。最后，有些人认为 DeltaV 还这样不流行主要是因为一直没有开源的服务器产品实现它。

当 Subversion 还在设计阶段时，使用 Apache 的 httpd 作为主要网络服务器就是一个很好的想法。它已经有了支持 WebDAV 服务的模块。DeltaV 是一个较新的规范。希望 Subversion 服务器模块(mod_dav_svn)最终能够成为一个开源的 DeltaV 参考实现。但非常不幸，DeltaV 的版本模型过于具体，并且与 Subversion 的模型并不匹配。虽然有些概念可以对应起来，但有些则不能。

这是什么意思呢？

首先，Subversion 客户端不是一个完全实现的 DeltaV 客户端。它需要从服务器得到 DeltaV 不能提供的东西，因此非常依赖于只有 mod_dav_svn 理解的 Subversion 特定的 REPORT 请求。

其次，mod_dav_svn 不是一个完全实现的 DeltaV 服务器，许多与 Subversion 不相关的 DeltaV 规范还没有实现。

A long-held debate in the Subversion developer community about whether it was worthfile to remedy either of these situations eventually reached closure, with the Subversion developers officially deciding to abandon plans to fully support DeltaV. New versions of Subversion will, of course, continue to provide the same DeltaV feature support already present in older releases, but no new work would be done to increase coverage of the specification—in fact, Subversion would intentionally begin to move away from strict DeltaV as its primary HTTP-based protocol.