因為Subversion客戶端不是完整的DeltaV客戶端，Subversion伺服器也不是完整的DeltaV伺服器，但仍有值得高興的交互特性：叫做自動版本化。

自動版本化是DeltaV標準中的可選特性，一個典型的DeltaV伺服器會拒絕一個對版本控制之下文件的PUT操作，為了修改一個版本控制下的文件，伺服器只會接受一系列正確的版本請求：例如MKACTIVITY、CHECKOUT、PUT和CHECKIN。但是如果DeltaV伺服器支持自動版本化，伺服器可以在後台假裝客戶端執行了一些列正確的版本請求，也就是說，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會做許多寫請求，導致了產生數量非常多的自動提交修訂版本。例如，當保存資料，許多客戶端會使用一個PUT一個0字節的文件，然後緊跟一個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-type，這個模塊查看文件的擴展名，有可能的話還包括檢查內容；如果文件符合某個常用模式，就會自動設定文件的svn;mime-type。