While the Subversion client is not a full DeltaV client, nor the Subversion server a full DeltaV server, there's still a glimmer of WebDAV interoperability to be happy about: it's called autoversioning.
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 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.
Because so many operating systems already have integrated WebDAV clients, the use case for this feature borders on fantastical: 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>
When SVNAutoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision.
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 filedata. The single
file-write results in two separate commits. Also consider that
many applications auto-save every few minutes, resulting in even
more commits.
If you have a post-commit hook program that sends email, for
example, you may want to disable email generation either
altogether, or on certain sections of the repository; it depends
on whether you think the influx of emails will still prove to be
valuable notifications or not. Also, a smart post-commit hook
program can distinguish between a transaction created via
autoversioning and one created through a normal svn
commit. The trick is to look for a revision property
named svn:autoversioned
. If present, the
commit was made by a generic WebDAV client.