虽然 Subversion 客户端不是完整的 DeltaV 客户端，Subversion 服务器也不是完整的 DeltaV 服务器，但仍然存在 WebDAV 互操作性的曙光：自动版本控制。

自动版本控制是 DeltaV 标准中定义的可选功能。典型的 DeltaV 服务器会拒绝无知的 WebDAV 客户端尝试对受版本控制的文件进行 PUT 操作。要更改受版本控制的文件，服务器需要一系列正确的版本控制请求：例如 MKACTIVITY、CHECKOUT、PUT、CHECKIN。但如果 DeltaV 服务器支持自动版本控制，则会接受来自基本 WebDAV 客户端的写入请求。服务器的行为就好像客户端已经发出了一系列正确的版本控制请求，并在后台执行提交操作。换句话说，它允许 DeltaV 服务器与不理解版本控制的普通 WebDAV 客户端进行互操作。

由于许多操作系统已经集成了 WebDAV 客户端，因此此功能的用例对与非技术用户合作的管理员来说非常有吸引力。想象一下一个由使用 Microsoft Windows 或 Mac OS 的普通用户组成的办公室。每个用户“挂载” Subversion 存储库，它看起来像一个普通的网络文件夹。他们像往常一样使用共享文件夹：打开文件、编辑文件并保存文件。与此同时，服务器会自动对所有内容进行版本控制。任何管理员（或有经验的用户）都可以使用 Subversion 客户端搜索历史记录并检索数据的旧版本。

这种情况并非虚构——它是真实存在的，而且有效。要在 mod_dav_svn 中激活自动版本控制，请在 httpd.conf 的 Location 块中使用 SVNAutoversioning 指令，如下所示

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

当 Subversion 自动版本控制处于活动状态时，来自 WebDAV 客户端的写入请求会导致自动提交。会自动生成一个通用日志消息并附加到每个修订版。

但是，在激活此功能之前，请先了解您将要面临什么。WebDAV 客户端往往会进行许多写入请求，导致大量的自动提交的修订版。例如，保存数据时，许多客户端会对一个 0 字节的文件执行 PUT 操作（作为保留名称的一种方式），然后用真实的文件数据执行另一个 PUT 操作。单个文件写入会导致两个独立的提交。还要考虑许多应用程序每隔几分钟就会自动保存一次，导致更多的提交。

如果您有一个 post-commit 钩子程序用于发送电子邮件，您可能想要完全禁用电子邮件生成，或者在存储库的某些部分禁用电子邮件生成；这取决于您是否认为大量邮件仍然是有价值的通知，还是不会。此外，一个智能的 post-commit 钩子程序可以区分通过自动版本控制创建的事务和通过正常的 Subversion 提交操作创建的事务。诀窍是查找名为 svn:autoversioned 的修订版属性。如果存在该属性，则提交操作是由通用的 WebDAV 客户端执行的。

另一个可能对 Subversion 的自动版本控制很有用的补充功能来自 Apache 的 mod_mime 模块。如果 WebDAV 客户端向存储库添加了新文件，则用户没有机会设置 svn:mime-type 属性。这可能会导致该文件在 WebDAV 共享文件夹中显示为通用图标，与任何应用程序都没有关联。一种补救方法是让系统管理员（或其他了解 Subversion 的人）检出一个工作副本，并手动在必要的文件上设置 svn:mime-type 属性。但是，这种清理任务可能永远不会结束。相反，您可以在 Subversion 的 <Location> 块中使用 ModMimeUsePathInfo 指令

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on

  ModMimeUsePathInfo on

</Location>

此指令允许 mod_mime 尝试自动推断通过自动版本控制进入存储库的新文件的 MIME 类型。该模块会查看文件的扩展名，以及文件的内容；如果文件与一些常见模式匹配，则会自动设置该文件的 svn:mime-type 属性。