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 服务器可用，包括微软自己的 IIS。

不幸的是，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 将继续提供与旧版本相同的 DeltaV 功能支持，但不会进行任何新的工作来增加对规范的覆盖范围——实际上，Subversion 会有意开始将其主要基于 HTTP 的协议从严格的 DeltaV 转变。