DAV 表示 “分布式创作与版本控制” (Distributed Authoring and Versioning). RFC 2518 为 HTTP 1.1 定义了 一系列的概念和相应的扩展, 使得 Web 成为一个更加通用的读写媒介. RFC 2518 的基本思想是支持 WebDAV 的服务器看起来就像是一个普通的文件服务器, 客户端可以 “挂载” 基于 HTTP 协议的共享目录, 这些共享目录 就像其他网络文件系统那样 (例如 NFS 和 SMB).

但不幸的是, 撇开名字不说, RFC 2518 并没有介绍任何形式的版本控制, 最基本的 WebDAV 客户端和服务器都假设文件或目录只存在一个版本, 而且可以 被重复写入.

由于 RFC 2518 没有介绍与版本控制相关的内容, 几年后, 另一个委员会 开始负责起草 RFC 3253. 新的 RFC 为 WebDAV 添加了与版本控制相关的内容, 在 “DAV” 后面加上了 “V”—于是有了术语 “DeltaV”. WebDAV/DeltaV 客户端和服务器经常被称作 “DeltaV” 程序, 因为 DeltaV 是 WebDAV 的超集.

原始的 WebDAV 标准获得了广泛的支持. 每一个现代化的操作系统都自带了 一个通用的 WebDAV 客户端 (后面会谈到细节), 还有很多流行的独立应用程序 都支持 WebDAV—Microsoft Office, Dreamweaver, 和 Photoshop. 在服务器端, Apache HTTP 服务器从 1998 年起就开始提供 WebDAV 服务, 除 了开源软件, 还有商业 WebDAV 服务器可供使用, 例如 Microsoft 的 IIS.

但不幸的是, DeltaV 就没这么成功. 支持 DeltaV 的客户端或服务器 非常少, 即使有, 也是不怎么知名的商业产品, 而且在不同产品之间进行互操作非 常困难. DeltaV 如此不受待见的原因不是非常清楚, 但有人觉得这是因为规范实 在太复杂了, 还有人觉得是 WebDAV 的功能已经足够吸引人了 (即使是最不懂技术 的用户也非常喜欢网络文件共享功能), 对于大多数用户而已, 版本控制功能并 不是非常有必要, 还有人觉得是因为还未出现支持 DeltaV 的开源服务器.

当 Subversion 还处于设计阶段时, 设计人员就觉得把 Apache 作为网络 服务器是一个好主意, 那时它已经具备了一个可以提供 WebDAV 服务的模块. DeltaV 在当时是一个相对较新的规范, 开发人员希望 Subversion 的服务器 模块 (mod_dav_svn) 最终可以演变成 DeltaV 的开源实现. 但不幸的是, DeltaV 有一个非常明确的版本控制模型, 而这个模型与 Subversion 并非完全契合, 有些概念可以互相映射, 但有些不行.

那么这会导致什么后果?

首先, Subversion 客户端并非是一个 DeltaV 客户端的完整实现. DeltaV 无法提供 Subversion 客户端所需的某些特定信息, 后者非常依赖于 Subversion 特有的 HTTP REPORT 请求, 而这些请求只有 mod_dav_svn 能够支持.

然后, mod_dav_svn 也不是一个 DeltaV 服务器的完整 实现. DeltaV 规范中的很多内容对 Subversion 没什么用, 于是 mod_dav_svn 就没有实现它们.

对于是否要去纠正上面所说的两种结果, Subversion 开发者社区最终达成 了一致, 他们正式宣布放弃完全支持 DeltaV 的计划. 在 Subversion 1.7, 客户端和服务器引入了大量的, 不标准的 DeltaV 简化实现^[81] 以后可能还会出现更多的 定制化实现. 新版 Subversion 仍然会继续提供旧版 Subversion 已有的 DeltaV 功能, 但不会继续增加对 DeltaV 标准规范的支持—Subversion 已经放弃 把严格的 DeltaV 作为它的主要的, 基于 HTTP 的协议.