Here is a very “high-level” description of how various Subversion client operations use DeltaV. In many cases, these explanations are gross oversimplifications. They should not be taken as a substitute for reading Subversion's source code or talking with its developers.

At the time of writing, the truth is that there are very few DeltaV clients in the world; RFC 3253 is still relatively new. However users do have access to “generic” clients, because almost every modern operating system now has an integrated basic WebDAV client. With this in mind, Subversion developers realized that if Subversion 1.0 was to have any interoperability features, support for DeltaV autoversioning would be the best approach.

To activate autoversioning in mod_dav_svn, use the SVNAutoversioning directive within the httpd.conf Location block, like so:

<Location /repos>
  DAV svn
  SVNPath /absolute/path/to/repository
  SVNAutoversioning on
</Location>

Normally, if a generic WebDAV client attempted a PUT to a path within your repository location, mod_dav_svn would outright reject the request. (It normally only allows such operations on “working resources” within DeltaV “activities”.) With SVNAutoversioning turned on, however, the server interprets the PUT request as an internal MKACTIVITY, CHECKOUT, PUT, and CHECKIN. A generic log message is auto-generated, and a new filesystem revision is created.

Because so many operating systems already have integrated WebDAV abilities, the use-case for this feature borders on fantastical: imagine an office of ordinary users running Microsoft Windows or Mac OS. Each computer “mounts” the Subversion repository, which appears to be an ordinary network share. They use the server as they always do: open files from the server, edit them, and save them back to the server. But in this fantasy, the server is automatically versioning everything. Later on, a sysadmin can use a Subversion client to search and retrieve all older versions.

Is this fantasy real? Not quite. The main snag is that Subversion 1.0 has no support whatsoever for the WebDAV LOCK or UNLOCK methods. Most operating system DAV clients attempt to LOCK a resource opened directly from a DAV-mounted network share. For now, users may have to copy a file from the DAV share to local disk, edit the file, then copy it back again. Not ideal autoversioning, but still doable.

The mod_dav Apache module is a complex beast: it understands and parses all of the WebDAV and DeltaV methods, yet it depends on a back-end “provider” to access the resources themselves.

In its simplest incarnation, a user can use mod_dav_fs as a provider for mod_dav. mod_dav_fs uses the ordinary filesystem to store files and directories, and only understands vanilla WebDAV methods, not DeltaV.

Subversion, on the other hand, uses mod_dav_svn as a provider for mod_dav. mod_dav_svn understands all WebDAV methods except LOCK, and understands a sizable subset of DeltaV methods. It accesses data in the Subversion repository, rather than in the real filesystem. Subversion 1.0 doesn't support locking, because it would actually be quite difficult to implement, since Subversion uses the copy-modify-merge model.^[46]

In Apache httpd-2.0, mod_dav supports the LOCK method by tracking locks in a private database, assuming that the provider is willing to accept them. In Apache httpd-2.1 or later, however, this locking support has been broken into an independent module, mod_dav_lock. It allows any mod_dav provider to take advantage of the lock database, including mod_dav_svn, even though mod_dav_svn doesn't actually understand locking.

Confused yet?

In a nutshell, you can use mod_dav_lock in Apache httpd-2.1 (or later) to create the illusion that mod_dav_svn is honoring LOCK requests. Make sure mod_dav_lock is either compiled into httpd, or being loaded in your httpd.conf. Then simply add the DAVGenericLockDB directive to your Location like so:

<Location /repos>
  DAV svn
  SVNPath /absolute/path/to/repository
  SVNAutoversioning on
  DavGenericLockDB /path/to/store/locks
</Location>

This technique is a risky business; in some sense, the mod_dav_svn is now lying to the WebDAV client. It claims to accept the LOCK request, but in reality the lock isn't being enforced at all levels. If a second WebDAV client attempts to LOCK the same resource, then mod_dav_lock will notice and correctly deny the request. But there's absolutely nothing preventing an ordinary Subversion client from changing the file via a normal svn commit! If you use this technique, you're giving users the opportunity to stomp on each others' changes. In particular, a WebDAV client might accidentally overwrite a change committed by regular svn client.

On the other hand, if you set up your environment very carefully, you may mitigate the risk. For example, if all of your users are working though basic WebDAV clients (rather than svn clients), then things should be fine.