Subversion クライアントはまだ完全な DeltaV クライアントではありませんし Subversion サーバも完全な DeltaV サーバではありませんが、 WebDAV 協調動作できるうれしい機能があります: それは自動バージョン化と 呼ばれるものです。
Autoversioning is an optional feature defined in the DeltaV standard. A typical DeltaV server will reject an ignorant WebDAV client attempting to do a PUT to a file that's under version control. To change a version-controlled file, the server expects a series of proper versioning requests: something like MKACTIVITY, CHECKOUT, PUT, CHECKIN. But if the DeltaV server supports autoversioning, then write-requests from basic WebDAV clients are accepted. The server behaves as if the client had issued the proper series of versioning requests, performing a commit under the hood. In other words, it allows a DeltaV server to interoperate with ordinary WebDAV clients that don't understand versioning.
Because so many operating systems already have integrated WebDAV clients, the use case for this feature can be incredibly appealing to administrators working with non-technical users: imagine an office of ordinary users running Microsoft Windows or Mac OS. Each user 「mounts」 the Subversion repository, which appears to be an ordinary network folder. They use the shared folder as they always do: open files, edit them, save them. Meanwhile, the server is automatically versioning everything. Any administrator (or knowledgeable user) can still use a Subversion client to search history and retrieve older versions of data.
This scenario isn't fiction: it's real and it works, as of Subversion 1.2 and later. To activate autoversioning in mod_dav_svn, use the SVNAutoversioning directive within the httpd.conf Location block, like so:
<Location /repos> DAV svn SVNPath /path/to/repository SVNAutoversioning on </Location>
SVNAutoversioning が有効な場合には WebDAV クライアントからの要求は 不分割なコミットとなります。一般的なログメッセージが自動生成され それぞれのリビジョンにつけられます。
Before activating this feature, however, understand what you're getting into. WebDAV clients tend to do many write requests, resulting in a huge number of automatically committed revisions. For example, when saving data, many clients will do a PUT of a 0-byte file (as a way of reserving a name) followed by another PUT with the real file data. The single file-write results in two separate commits. Also consider that many applications auto-save every few minutes, resulting in even more commits.
たとえばメールを送信するようなpost-commitのフックプログラムがある 場合、email 生成を完全に禁止したいと思うか、リポジトリの特定の部分に 関して禁止したいと思うかも知れません; それは email の流入量が 意味のある通知と考えられるかどうかにかかっています。さらに、賢い post-commitフックプログラムは自動バージョン化機能によって発生した トランザクションと通常の svn commitによって発生したトランザクションとを区別する ことができます。これには svn:autoversionedという 名前のリビジョンプロパティーを見るとうまくいきます。もし存在して いればそのコミットは一般的な WebDAV クライアントによるものです。
Another feature that may be a useful complement for SVNAutoversioning comes from Apache's mod_mime module. If a WebDAV client adds a new file to the repository, there's no opportunity for the user to set the the svn:mime-type property. This might cause the file to appear as generic icon when viewed within a WebDAV shared folder, not having an association with any application. One remedy is to have a sysadmin (or other Subversion-knowledgeable person) check out a working copy and manually set the svn:mime-type property on necessary files. But there's potentially no end to such cleanup tasks. Instead, you can use the ModMimeUsePathInfo directive in your Subversion <Location> block:
<Location /repos> DAV svn SVNPath /path/to/repository SVNAutoversioning on ModMimeUsePathInfo on </Location>
This directive allows mod_mime to attempt automatic deduction of the mime-type on new files that enter the repository via autoversioning. The module looks at the file's named extension and possibly the contents as well; if the file matches some common patterns, then the the file's svn:mime-type property will be set automatically.