虽然 Subversion 客户端不是完整的 DeltaV 客户端，Subversion 服务器也不是完整的 DeltaV 服务器，但我们仍然可以从 WebDAV 的互操作性中获得一些喜悦：这就是自动版本控制。

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

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

这种情况并非虚构：它是真实的，而且从 Subversion 1.2 及更高版本开始就可行。要在 mod_dav_svn 中激活自动版本控制，请在 httpd.conf 的 Location 块中使用 SVNAutoversioning 指令，如下所示：

<Location /repos>
  DAV svn
  SVNPath /path/to/repository
  SVNAutoversioning on
</Location>

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

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

如果您有一个 post-commit 钩子程序，它会发送电子邮件，您可能需要完全禁用电子邮件生成，或者在存储库的某些部分禁用电子邮件生成；这取决于您是否认为大量涌入的电子邮件仍然是有价值的通知。

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

<Location /repos>
  DAV svn
  SVNPath /path/to/repository
  SVNAutoversioning on

  ModMimeUsePathInfo on

</Location>

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