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 now have 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 shared folders that behave much like NFS or SMB filesystems.
The tragedy, though, is that the RFC 2518 WebDAV specification 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.
Here are the concepts and terms introduced in basic WebDAV:
WebDAV lingo refers to any server-side object (that can be described with a URI) as a resource.
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.
A collection is the WebDAV
term for a grouping of resources. In most cases, it
is analogous to a directory. 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 in some server
implementations.
A more recent specification (RFC 3744) defines a system for defining access control lists (ACLs) on WebDAV resources. Some clients and servers have begun to implement this feature.
Because RFC 2518 left out versioning concepts, another committee was left with the responsibility of writing RFC 3253, which adds versioning to WebDAV, a.k.a. “DeltaV”. WebDAV/DeltaV clients and servers are often called just “DeltaV” programs, 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:
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.
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 resources 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.
Some DeltaV servers also support the idea that the
client may have a private working copy on local disk.
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
resource it wishes to change and sends
PUT requests. Finally, the client
performs a CHECKIN resource, or
sends a MERGE request to check in
all resources at once.
DeltaV allows you define flexible collections of resources called “configurations”, which don't necessarily correspond to particular directories. A configuration can be made to point to specific versions of files, and then a “baseline” snapshot can be made, much like a tag.
DeltaV defines a new method,
REPORT, which allows the client and
server to perform customized data exchanges. While
DeltaV defines a number of standardized history reports
that a client can request, the server is also free
to define custom reports. 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.