This text is a work in progress—highly subject to
change—and may not accurately describe any released
version of the Apache™ Subversion® software.
Bookmarking or otherwise referring others to this page is
probably not such a smart idea. Please visit
http://www.svnbook.com/
for stable versions of this book.

What Is WebDAV?

DAV stands
for “Distributed Authoring and Versioning.” RFC
2518 defines a set of concepts and accompanying extension
methods to HTTP 1.1 that make the Web 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 over HTTP that behave
much like other network filesystems (such as NFS or SMB).

The tragedy, though, is that despite the acronym, the RFC
specification doesn't actually describe any sort of version
control. Basic WebDAV clients and servers assume that only one
version of each file or directory exists, and that it can be
repeatedly overwritten.

Because RFC 2518 left out versioning concepts, another
committee was left with the responsibility of writing RFC 3253 a
few years later. The new RFC adds versioning concepts to
WebDAV, placing the “V” back in
“DAV”—hence the term “DeltaV.”
WebDAV/DeltaV clients and servers are often called just
“DeltaV” programs, since DeltaV implies the
existence of basic WebDAV.

The original WebDAV standard has been widely successful.
Every modern computer operating system has a general WebDAV
client built in (details to follow), and a number of popular
standalone applications are also able to speak
WebDAV—Microsoft Office, Dreamweaver, and Photoshop, to
name a few. On the server end, Apache HTTP Server has been
able to provide WebDAV services since 1998 and is considered the
de facto open source standard. Several other
commercial WebDAV servers are available, including Microsoft's own
IIS.

DeltaV, unfortunately, has not been so successful. It's
very difficult to find any DeltaV clients or servers. The few
that do exist are relatively unknown commercial products, and
thus it's very difficult to test interoperability. It's not
entirely clear as to why DeltaV has remained stagnant. Some
opine that the specification is just too complex. Others argue
that while WebDAV's features have mass appeal (even the least
technical users appreciate network file sharing), its version
control features just aren't interesting or necessary for most
users. Finally, some believe that DeltaV remains unpopular
because there's still no open source server product that
implements it well.

When Subversion was still in its design phase, it seemed
like a great idea to use Apache as a network server. It already
had a module to provide WebDAV services. DeltaV was a
relatively new specification. The hope was that the Subversion
server module (mod_dav_svn) would eventually
evolve into an open source DeltaV reference implementation.
Unfortunately, DeltaV has a very specific versioning model that
doesn't quite line up with Subversion's model. Some concepts
were mappable; others were not.

What does this mean, then?

First, the Subversion client is not a fully implemented
DeltaV client. It needs certain types of things from the server
that DeltaV itself cannot provide, and thus is largely dependent
on a number of Subversion-specific
HTTP REPORT requests that
only mod_dav_svn understands.

Second, mod_dav_svn is not a
fully realized DeltaV server. Many portions of the DeltaV
specification were irrelevant to Subversion, and thus were left
unimplemented.

A long-held debate in the Subversion developer community
about whether it was worthfile to remedy either of these
situations eventually reached closure, with the Subversion
developers officially deciding to abandon plans to fully support
DeltaV. As of Subversion 1.7, Subversion clients and servers
introduce numerous non-standard simplifications of the DeltaV
standards[85], with more
customizations of this sort likely to come. Those versions of
Subversion will, of course, continue to provide the same DeltaV
feature support already present in older releases, but no new
work will be done to increase coverage of the
specification—Subversion is intentionally moving away from
strict DeltaV as its primary HTTP-based protocol.

[85] The Subversion developers colloquially
refer to this deviation from the DeltaV standard
as “HTTPv2”.