Table of Contents
WebDAV is an extension to HTTP, and is growing more and more popular as a standard for file-sharing. Today's operating systems are becoming extremely Web-aware, and many have now built-in support for mounting “shares” exported by WebDAV servers.
If you use Apache/mod_dav_svn as your Subversion network server, then to some extent, you are also running a WebDAV server. This appendix gives some background on the nature of this protocol, how Subversion uses it, and how well Subversion interoperates with other software that is WebDAV-aware.
This section provides a very brief, very general overview to the ideas behind WebDAV. It should lay the foundation for understanding WebDAV compatibility issues between clients and servers.
RFC 2518 defines a set of concepts and accompanying extension methods to HTTP 1.1 that make the web into a more universal read/write medium. The basic idea is that a WebDAV-compliant web server can act like a generic file server; clients can mount WebDAV “shares” that behave much like NFS or SMB shares.
However, it's important to note that RFC 2518 does not provide any sort of model for version control, despite the “V” in DAV. Basic WebDAV clients and servers assume only one version of each file or directory exists, and can be repeatedly overwritten. [45]
Here are the new concepts and methods introduced in basic WebDAV:
Beyond the standard HTTP PUT method (which creates or overwrites a web resource), WebDAV defines new COPY and MOVE methods for duplicating or rearranging resources.
This is simply the WebDAV term for a grouping of resources (URIs). In most cases, it is analogous to a “directory”. You can tell something is a collection if it ends with a trailing “/”. Whereas file resources can be written or created with a PUT method, collection resources are created with the new MKCOL method.
This is the same idea present in Subversion—metadata attached to files and collections. A client can list or retrieve properties attached to a resource with the new PROPFIND method, and can change them with the PROPPATCH method. Some properties are wholly created and controlled by users (e.g. a property called “color”), and others are wholly created and controlled by the WebDAV server (e.g. a property that contains the last modification time of a file). The former kind are called “dead” properties, and the latter kind are called “live” properties.
A WebDAV server may decide to offer a locking feature to clients—this part of the specification is optional, although most WebDAV servers do offer the feature. If present, then clients can use the new LOCK and UNLOCK methods to mediate access to a resource. In most cases these methods are used to create exclusive write locks (as discussed in the section called “The Lock-Modify-Unlock Solution”), although shared write locks are also possible.
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:
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.
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.
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.
DeltaV allows you define flexible collections of VCRs called “configurations”, which don't necessarily respond 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.
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.
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.