DAV 代表 “分布式创作和版本控制”。RFC 2518 定义了一组概念以及与 HTTP 1.1 相关的扩展方法，这些方法使 Web 成为一个更通用的读写媒介。基本思想是，符合 WebDAV 标准的 Web 服务器可以充当通用文件服务器；客户端可以 “挂载” 通过 HTTP 共享的文件夹，这些文件夹的行为类似于其他网络文件系统（如 NFS 或 SMB）。

然而，不幸的是，尽管有这个首字母缩略词，但 RFC 规范实际上并没有描述任何形式的版本控制。基本的 WebDAV 客户端和服务器假设每个文件或目录只有一个版本，并且该版本可以被重复覆盖。

由于 RFC 2518 省略了版本控制概念，因此几年后另一个委员会负责编写 RFC 3253。新的 RFC 将版本控制概念添加到 WebDAV 中，将 “V” 放回了 “DAV” 中，因此产生了术语 “DeltaV”。WebDAV/DeltaV 客户端和服务器通常简称为 “DeltaV” 程序，因为 DeltaV 意味着基本 WebDAV 的存在。

最初的 WebDAV 标准已经取得了广泛的成功。每个现代计算机操作系统都内置了一个通用的 WebDAV 客户端（详细信息如下），许多流行的独立应用程序也能够使用 WebDAV 协议，例如 Microsoft Office、Dreamweaver 和 Photoshop。在服务器端，Apache HTTP Server 自 1998 年以来就能够提供 WebDAV 服务，并且被认为是事实上的开源标准。还有其他几种商业 WebDAV 服务器可用，包括 Microsoft 自身的 IIS。

不幸的是，DeltaV 并没有那么成功。很难找到任何 DeltaV 客户端或服务器。少数存在的 DeltaV 客户端和服务器是相对不知名的商业产品，因此很难测试互操作性。DeltaV 停滞不前的确切原因尚不清楚。有些人认为规范太复杂了。另一些人认为，虽然 WebDAV 的功能具有广泛的吸引力（即使是最不了解技术的用户也欣赏网络文件共享），但其版本控制功能对于大多数用户来说并没有那么有趣或必要。最后，有些人认为 DeltaV 仍然不受欢迎是因为仍然没有开源服务器产品能够很好地实现它。

当 Subversion 还在设计阶段时，使用 Apache 作为网络服务器似乎是一个好主意。它已经有一个模块来提供 WebDAV 服务。DeltaV 是一个相对较新的规范。希望 Subversion 服务器模块（mod_dav_svn）最终会发展成为一个开源 DeltaV 参考实现。不幸的是，DeltaV 具有非常具体的版本控制模型，它与 Subversion 的模型并不完全一致。有些概念是可以映射的；而另一些则不能。

那么这意味着什么呢？

首先，Subversion 客户端不是一个完全实现的 DeltaV 客户端。它需要服务器提供某些类型的功能，而这些功能是 DeltaV 本身无法提供的，因此它在很大程度上依赖于许多 Subversion 特定的 HTTP REPORT 请求，只有 mod_dav_svn 才能理解。

其次，mod_dav_svn 不是一个完全实现的 DeltaV 服务器。DeltaV 规范的许多部分与 Subversion 无关，因此未被实现。

Subversion 开发者社区中长期存在的一个关于是否值得解决这两个问题之一的争论最终得到了解决，Subversion 开发者正式决定放弃完全支持 DeltaV 的计划。从 Subversion 1.7 开始，Subversion 客户端和服务器引入了许多对 DeltaV 标准的非标准简化^[85]，并且这种类型的自定义可能会越来越多。这些版本的 Subversion 当然会继续提供与旧版本相同的 DeltaV 功能支持，但不会进行任何新的工作来增加对规范的覆盖范围——Subversion 正在有意地从严格的 DeltaV 作为其主要基于 HTTP 的协议中迁移。