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 规范还没有实现。

在开发者社区一直有这样的讨论，这种情况是否值得补救。改变 Subversion 的设计来匹配 DeltaV 看起来相当不现实，所以可能没有办法让客户端从普通的 DeltaV 服务器上得到所有的东西。另一方面，mod_dav_svn 可以继续开发来实现所有的 DeltaV 特性，但缺乏这样做的动力—几乎没有能与之交户的 DeltaV 客户端。