WebDAV and Autoversioning

Because RFC 2518 left out versioning concepts, another capable group was left with the responsibility of writing RFC 3253, which adds versioning to WebDAV. WebDAV/DeltaV clients and servers are often called just “DeltaV” clients and servers, since DeltaV implies the existence of basic WebDAV.

DeltaV introduces a whole slew of new acronyms, but don't be intimidated. The ideas are fairly straightforward. Here are the new concepts and methods introduced in DeltaV:

Per-resource versioning

Like CVS and other version-control systems, DeltaV assumes that each resource has a potentially infinite number of states. A client begins by placing a resource under version control using the new VERSION-CONTROL method. This creates a new Version Controlled Resource (VCR). Every time you change the VCR (via PUT, PROPPATCH, etc.), a new state of the resource is created, called a Version Resource (VR). VCRs and VRs are still ordinary web resources, defined by URLs. Specific VRs can have human-friendly names as well.

Server-side working-copy model

Some DeltaV servers support the ability to create a virtual “workspace” on the server, where all of your work is performed. Clients use the MKWORKSPACE method to create a private area, then indicate they want to change specific VCRs by “checking them out” into the workspace, editing them, and “checking them in” again. In HTTP terms, the sequence of methods would be CHECKOUT, PUT, CHECKIN. After each CHECKIN, a new VR is created, and the edited VCR's contents now “point to” the latest VR. Each VCR has also has a “history” resource which tracks and orders its various VR states.

Client-side working-copy model

Some DeltaV servers also support the idea that the client may have a private working copy full of specific VRs. (This is how CVS and Subversion work.) When the client wants to commit changes to the server, it begins by creating a temporary server transaction (called an activity) with the MKACTIVITY method. The client then performs a CHECKOUT on each VR it wishes to change, which creates a number of temporary “working resources” in the activity, that can be modified using PUT and PROPPATCH methods. Finally, the client performs a CHECKIN on each working resource, which creates a new VR within each VCR, and the entire activity is deleted.

Configurations

DeltaV allows you define flexible collections of VCRs called “configurations”, which don't necessarily correspond to particular directories. Each VCR's contents can be made to point to a specific VR using the UPDATE method. Once the configuration is perfect, the client can create a “snapshot” of the whole configuration, called a “baseline”. Clients use the CHECKOUT and CHECKIN methods to capture specific states of configurations, much like they use these methods to create specific VR states of VCRs.

Extensibility

DeltaV defines a new method, REPORT, which allows the client and server to perform customized data exchanges. The client sends a REPORT request with a properly-labeled XML body full of custom data; assuming the server understands the specific report-type, it responds with an equally custom XML body. This technique is very similar to XML-RPC.

Autoversioning

For many, this is the “killer” feature of DeltaV. If the DeltaV server supports this feature, then basic WebDAV clients (i.e. those unaware of versioning) can still write to the server, and the server will silently perform versioning anyway. In the simplest example, an ignorant PUT from a basic WebDAV client might be translated by the server as a CHECKOUT, PUT, CHECKIN.

Subversion and DeltaV

So how “compatible” is Subversion with other DeltaV software? In two words: not very. At least not yet, not in Subversion 1.0.

269

WebDAV and Autoversioning

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.

Mapping Subversion to DeltaV

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.

svn checkout/list

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.

svn commit

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.

svn update/switch/status/merge/diff

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.

Autoversioning Support

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 ver-

270