虽然 Subversion 客户端和服务器都不是一个完整的 DeltaV 客户端和服务器, 但仍然存在值得人们高兴的 WebDAV 互操作性: 自动版本控制 (autoversioning).

自动版本控制是 DeltaV 标准定义的可选功能. 如果客户端尝试在一个 被版本控制的文件上执行 PUT 操作, 一个典型的 DeltaV 服务器将会拒绝这个操作. 为了修改被版本控制的文件, 服务器希望收到一系列 合理的版本控制请求, 就像 MKACTIVITY, CHECKOUT, PUT 和 CHECKIN. 但是, 如果 DeltaV 服务器支持自动版本控制, 来自 WebDAV 客户端的写请求将会被接受, 服务器的表现就像是客户端 已经 发送了一系列的版本控制请求, 并且在底层执行 了提交操作. 换句话说, 自动版本控制允许 DeltaV 服务器与普通的, 不了解 版本控制的 WebDAV 客户端实现互操作.

由于很多操作系统已经内建了 WebDAV 客户端, 因此自动版本控制对于 经常和非技术用户打交道的管理员来说非常有吸引力. 假设在一个由普通人组成 的办公室中, 人们都是使用 Microsoft Windows 和 Mac OS, 每个人都 “挂载” 了 Subversion 仓库, 看起来就是一个普通的网络共享 目录, 他们可以按照和原来一样的步骤使用共享目录: 打开文件, 编辑文件, 然后保存. 同时, 版本控制将由服务器自动完成. 管理员 (或懂得技术的用户) 仍然可以使用 Subversion 客户端来搜索修改历史和检索数据的旧版本.

上面所说的场景并非虚构—它是真实存在的, 而且工作得很好. 为了 开启 mod_dav_svn 的自动版本控制功能, 在 Apache 配置文件 httpd.conf 的 Location 配置块里, 加上配置指令 SVNAutoversioning, 就像:

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

当 Subversion 的自动版本控制功能开启后, 来自 WebDAV 客户端的写 请求将会生成自动的提交, 其日志消息也是自动生成.

在开启自动版本控制之前, 管理员需要明白这会导致什么后果. WebDAV 客户端倾向于执行 “很多” 写请求, 这会产生更多的自动提交. 例如, 保存文件时, 许多 WebDAV 客户端将先做一次空文件的 PUT 操作 (为了占住文件名), 接下来再为真正的文件 内容做另一次 PUT 操作, 一次单独的写操作将生成两 次分开的提交. 同时还要考虑到很多应用程序每隔几分钟, 就会自动保存一次, 这会产生更多的自动提交.

如果管理员使用钩子 post-commit 来发送邮件, 那么他可能想要完全禁止 或者只在仓库的某些部分上禁止邮件通知, 这取决于管理员是否还觉得大量 涌入的通知邮件仍然值得阅读. 另外, 一个聪明的 post-commit 应该能够 区分某个提交是由自动版本控制生成的, 还是由通常的 Subversion 提交操作 生成的, 区分的技巧是查看版本号属性 svn:autoversioned, 如果该属性存在, 则说明该版本号是由 WebDAV 客户端生成的.

为了使 Subversion 的自动版本控制更加完整, 需要用到 Apache 的 mod_mime 模块. 如果 WebDAV 客户端为仓库添加了一个 新文件, 用户将没有机会设置新文件的 svn:mime-type 属性, 这可能会导致当用户在 WebDAV 共享目录中浏览文件时, 文件的图标 是一个通用图标, 不与任何打开程序关联. 一种解决办法是由管理员 (或懂得 技术的用户) 检出一个工作副本, 然后手工修改文件的 svn:mime-type 属性. 但这种做法似乎很麻烦, 特别是当 文件数量特别巨大时, 更好的做法是在 Apache 配置文件 httpd.conf 的 Location 配置块里, 加上配置指令 ModMimeUsePathInfo:

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

  ModMimeUsePathInfo on

</Location>

当新文件通过自动版本控制被添加到仓库中时, 配置指令 ModMimeUsePathInfo 允许 mod_mime 模块去尝试推导新文件的 MIME 类型. 为了推导文件的 MIME 类型, mod_mime 模块会去查看文件的推展名和内容, 如果符合 某种常见模式, 将自动设置 svn:mime-type 属性.