虽然 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 钩子程序用于发送电子邮件，您可能希望完全禁用电子邮件生成，或者在存储库的某些部分禁用电子邮件生成；这取决于您是否认为电子邮件的涌入仍然是有价值的通知，还是仅仅是一种负担。另外，一个智能的 post-commit 钩子程序可以区分通过自动版本控制创建的事务和通过正常 svn commit 创建的事务。诀窍是寻找一个名为 svn:autoversioned 的修订版属性。如果存在，则提交是由一个通用的 WebDAV 客户端完成的。

另一个可能对 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 属性将自动设置。