虽然 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 客户端往往会执行大量写操作，导致产生大量自动提交的版本。例如，在保存数据时，许多客户端会先执行一个PUT 操作，将一个 0 字节的文件写入（作为保留名称的方式），然后执行另一个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 属性将被自动设置。