DAV 代表“分布式创作与版本控制”。RFC 2518 定义了一组概念和相应的 HTTP 1.1 扩展方法，将网络转变为更通用的读写介质。基本思想是，兼容 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 Web 服务器自 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 的设计以匹配 DeltaV 是很不现实的，因此客户端可能永远无法从一般的 DeltaV 服务器中获得它需要的一切。另一方面，mod_dav_svn 可以进一步开发以实现所有 DeltaV，但很难找到这样做的动力——几乎没有 DeltaV 客户端可以与其互操作。