So how “compatible” is Subversion with other DeltaV software? In two words: not very. At least not yet, not in Subversion 1.0.
While libsvn_ra_dav sends DeltaV requests to the server, the
Subversion client is not a general-purpose
DeltaV client. In fact, it expects some custom features from
the server (especially through custom REPORT
requests). Further, mod_dav_svn is not a
general-purpose DeltaV server. It only implements a strict
subset of the DeltaV specification. A more general WebDAV or
DeltaV client may very well be able to interoperate against it,
but only if that client operates within the narrow confines of
those features that the server has implemented. The Subversion
development team plans to address general WebDAV
interoperability in a future release of Subversion.
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.
Perform a PROPFIND
of depth 1 on the
collection to get a list of immediate children. Perform
a GET
(and possibly a
PROPFIND
) on each child. Recurse
into collections and repeat.
Create an activity with MKACTIVITY
,
and do a CHECKOUT
of each changed
item, followed by a PUT
of new data.
Finally, a MERGE
request causes an
implicit CHECKIN
of all working
resources.
Send a custom REPORT
request that
describes the mixed-revision (and mixed-url) state of
the working copy. The server sends a custom response
that describes which items need updating and includes
binary deltas of file contents. Parses the response.
For updates and switches, install the new data in the
working copy. For diff and merge commands, compare the
data to the working copy, possibly applying changes as
local modifications.
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.
[46] Subversion may someday develop a reserved-checkout locking model that can live peaceably with copy-modify-merge, but it probably won't happen soon.