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

自动版本控制是 DeltaV 标准中定义的一个可选功能。典型的 DeltaV 服务器会拒绝试图对版本控制下的文件执行 PUT 操作的无知 WebDAV 客户端。要更改版本控制下的文件，服务器需要一系列正确的版本控制请求：类似于 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 属性将被自动设置。