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
.