WebDAV and Autoversioning - Version Control with Subversion

WebDAV is an extension to HTTP, and it 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.

This excerpt is from Version Control with Subversion.
Written by members of the development that maintains Subversion, this is the official guide and reference manual for the popular open source revision control technology. The new edition covers Subversion 1.5 and includes an introduction to Subversion, a guided tour of the capabilities and structure, detailed coverage of advanced topics, such as branching and repository
administration, and best practice recommendations.

If you use Apache as your Subversion network server, to some extent
you are also running a WebDAV server. This appendix provides some background
on the nature of this protocol, how Subversion uses it, and how well
Subversion interoperates with other software that is WebDAV-aware.

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
stuck 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 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 it 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 were thus left unimplemented.

There is still some debate in the developer community as to whether
it’s worthwhile to remedy either of these situations. It’s fairly
unrealistic to change Subversion’s design to match DeltaV, so there’s
probably no way the client can ever learn to get everything it needs from
a general DeltaV server. On the other hand, mod_dav_svncould be
further developed to implement all of DeltaV, but it’s hard to find
motivation to do so—there are almost no DeltaV clients to interoperate
with.

Autoversioning

Although the Subversion client is not a full DeltaV client, and the
Subversion server is not a full DeltaV server, there’s still a glimmer of
WebDAV interoperability to be happy about:
autoversioning.

Autoversioning is an optional feature defined in the DeltaV
standard. A typical DeltaV server will reject an ignorant WebDAV client
attempting to do a PUT to a file that’s
under version control. To change a version-controlled file, the server
expects a series of proper versioning requests: something like MKACTIVITY, CHECKOUT, PUT, CHECKIN.
But if the DeltaV server supports autoversioning, write requests from
basic WebDAV clients are accepted. The server behaves as though the client
had issued the proper series of versioning requests,
performing a commit under the hood. In other words, it allows a DeltaV
server to interoperate with ordinary WebDAV clients that don’t understand
versioning.

Because so many operating systems have already integrated WebDAV
clients, the use case for this feature can be incredibly appealing to
administrators working with nontechnical users. Imagine an office of
ordinary users running Microsoft Windows or Mac OS. Each user
“mounts” the Subversion repository, which appears to be an
ordinary network folder. They use the shared folder as they always do:
open files, edit them, and save them. Meanwhile, the server is
automatically versioning everything. Any administrator (or knowledgeable
user) can still use a Subversion client to search history and retrieve
older versions of data.

This scenario isn’t fiction—it’s real and it works, as of Subversion
1.2 and later. To activate autoversioning in mod_dav_svn, use the SVNAutoversioning
directive within the httpd.confLocation block, like so:

When Subversion autoversioning is active, write requests from WebDAV
clients result in automatic commits. A generic log message is
automatically generated and attached to each revision.

Before activating this feature, however, understand what you’re
getting into. WebDAV clients tend to do many write
requests, resulting in a huge number of automatically committed revisions.
For example, when saving data, many clients will do a PUT of a 0-byte file (as a way of reserving a name),
followed by another PUT with the real
file data. The single file-write results in two separate commits. Also
consider that many applications autosave every few minutes, resulting in
even more commits.

If you have a post-commit hook program that sends
email, you may want to disable email generation either altogether or on
certain sections of the repository; it depends on whether you think the
influx of emails will still prove to be valuable notifications. Also, a
smart post-commit hook program can distinguish between
a transaction created via autoversioning and one created through a normal
Subversion commit operation. The
trick is to look for a revision property named svn:autoversioned. If present, the commit was
made by a generic WebDAV client.

Another feature that may be a useful complement for Subversion’s
autoversioning comes from Apache’s mod_mime module. If a WebDAV client adds a new file to the repository, there’s
no opportunity for the user to set the svn:mime-type property. This might cause the
file to appear as a generic icon when viewed within a WebDAV shared
folder, not having an association with any application. One remedy is to
have a sysadmin (or other
Subversion-knowledgeable person) check out a working copy and manually set
the svn:mime-type property on necessary
files. But there’s potentially no end to such cleanup tasks. Instead, you
can use the ModMimeUsePathInfo
directive in your Subversion <Location> block:

This directive allows mod_mime to
attempt automatic deduction of the MIME type on new files that enter the
repository via autoversioning. The module looks at the file’s named
extension and possibly the contents as well; if the file matches some
common patterns, the file’s svn:mime-type property will be set
automatically.

Client Interoperability

All WebDAV clients fall into one of three categories: standalone applications,
file-explorer extensions, or filesystem implementations. These categories
broadly define the types of WebDAV functionality available to users. Table C.1, “Common WebDAV clients” gives our categorization as well as
a quick description of some common pieces of WebDAV-enabled software. You
can find more details about these software offerings, as well as their
general category, in the sections
that follow.

Web production software able to directly read from and
write to WebDAV URLs

Microsoft Office

Standalone WebDAV application

X

Office productivity suite with several components able to
directly read from and write to WebDAV URLs

Microsoft Web Folders

File-explorer WebDAV extension

X

GUI file-explorer program able to perform tree operations
on a WebDAV share

GNOME Nautilus

File-explorer WebDAV extension

X

GUI file explorer able to perform tree operations on a
WebDAV share

KDE Konqueror

File-explorer WebDAV extension

X

GUI file explorer able to perform tree operations on a
WebDAV share

Mac OS X

WebDAV filesystem implementation

X

Operating system that has built-in support for mounting
WebDAV shares

Novell NetDrive

WebDAV filesystem implementation

X

Drive-mapping program for assigning Windows drive letters
to a mounted remote WebDAV share

SRT WebDrive

WebDAV filesystem implementation

X

File transfer software, which, among other things, allows
the assignment of Windows drive letters to a mounted remote WebDAV
share

davfs2

WebDAV filesystem implementation

X

Linux filesystem driver that allows you to mount a WebDAV
share

Standalone WebDAV Applications

A WebDAV application is a program that speaks WebDAV protocols with
a WebDAV server. We’ll cover some of the most popular programs with this
kind of WebDAV support.

Microsoft Office, Dreamweaver, Photoshop

On Windows, several well-known applications contain integrated
WebDAV client functionality, such as Microsoft’s Office,[61] Adobe’s Photoshop and Dreamweaver programs. They’re able
to directly open and save to URLs, and tend to make heavy use of
WebDAV locks when editing a file.

Note that while many of these programs also exist for Mac OS X,
they do not appear to support WebDAV directly on that
platform. In fact, on Mac OS X, the File→Open dialog box doesn’t allow one to
type a path or URL at all. It’s likely that the WebDAV features were
deliberately left out of Macintosh versions of these programs, since
OS X already provides such excellent low-level filesystem support for
WebDAV.

cadaver, DAV Explorer

cadaver is a bare-bones Unix command-line program for browsing
and changing WebDAV shares. Like the Subversion client, it uses the
neon HTTP library—not surprisingly, since both neon and cadaver are
written by the same author. cadaver is free software (GPL license) and
is available at http://www.webdav.org/cadaver/.

Using cadaver is similar to using a command-line FTP program,
and thus it’s extremely useful for basic WebDAV debugging. It can be
used to upload or download files in a pinch, to examine properties,
and to copy, move, lock, or unlock files:

DAV Explorer is another standalone WebDAV client, written in Java. It’s under a
free Apache-like license and is available at http://www.ics.uci.edu/~webdav/. It does everything
cadaver does but has the advantages of being portable and being a more
user-friendly GUI application. It’s also one of the first clients to
support the new WebDAV Access Control Protocol (RFC 3744).

Of course, DAV Explorer’s ACL support is useless in this case,
since mod_dav_svn doesn’t support
it. The fact that both cadaver and DAV Explorer support some limited
DeltaV commands isn’t particularly useful either, since they don’t
allow MKACTIVITY requests. But it’s
not relevant anyway; we’re assuming all of these clients are operating
against an autoversioning repository.

File-Explorer WebDAV Extensions

Some popular file explorer GUI programs support WebDAV extensions that allow
a user to browse a DAV share as though it was just another directory on
the local computer and to perform
basic tree editing operations on the items in that share. For example,
Windows Explorer is able to browse a WebDAV server as a “network
place.” Users can drag files to and from the desktop, or can
rename, copy, or delete files in the usual way. But because it’s only a
feature of the file explorer, the DAV share isn’t visible to ordinary
applications. All DAV interaction must happen through the explorer
interface.

Microsoft Web Folders

Microsoft was one of the original backers of the WebDAV specification
and first started shipping a client in Windows 98, which was known as
Web Folders. This client was also shipped in Windows NT 4.0 and
Windows 2000.

The original Web Folders client was an extension to Explorer,
the main GUI program used to browse filesystems. It works well enough.
In Windows 98, the feature might need to be explicitly installed if
Web Folders aren’t already visible inside My Computer. In Windows
2000, simply add a new “network place,” enter the URL,
and the WebDAV share will pop up for browsing.

With the release of Windows XP, Microsoft started shipping a new
implementation of Web Folders, known as the WebDAV Mini-Redirector.
The new implementation is a filesystem-level client, allowing WebDAV
shares to be mounted as drive letters. Unfortunately, this
implementation is incredibly buggy. The client usually tries to
convert HTTP URLs (http://host/repos) into Universal Naming
Convention (UNC) share notation
(\\host\repos); it also often tries to
use Windows Domain authentication to respond to basic-auth HTTP
challenges, sending usernames as HOST\username. These interoperability
problems are severe and are documented in numerous places around the
Web, to the frustration of many users. Even Greg Stein, the original
author of Apache’s WebDAV module, bluntly states that XP Web Folders
simply can’t operate against an Apache server.

Windows Vista’s initial implementation of Web Folders seems to
be almost the same as XP’s, so it has the same sort of problems. With
luck, Microsoft will remedy these issues in a Vista Service
Pack.

However, there seem to be workarounds for both XP and Vista that
allow Web Folders to work against Apache. Users have mostly reported
success with these techniques, so we’ll relay them here.

On Windows XP, you have two options. First, search Microsoft’s web site
for update KB90730, “Software Update for Web Folders.”
This may fix all your problems. If it doesn’t, it seems that the
original pre-XP Web Folders implementation is still buried within the
system. You can unearth it by going to Network Places and adding a new
network place. When prompted, enter the URL of the repository, but
include a port number in the URL. For example,
you should enter http://host/repos as
http://host:80/repos instead. Respond to any
authentication prompts with your Subversion credentials.

On Windows Vista, the same KB90730 update may clear everything
up. But there may still be other issues. Some users have reported that
Vista considers all http://
connections insecure, and thus will always fail any authentication
challenges from Apache unless the connection happens over https://. If you’re unable to connect to the
Subversion repository via SSL, you can tweak the system registry to
turn off this behavior. Just change the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel
key from 1 to 2. A final
warning: be sure to set up the Web Folder to point to the repository’s
root directory (/), rather than
some subdirectory such as /trunk.
Vista Web Folders seems to work only against repository roots.

In general, while these workarounds may function for you, you
might get a better overall experience using a third-party WebDAV
client such as WebDrive or NetDrive.

Nautilus, Konqueror

Nautilus is the official file manager/browser for the GNOME desktop
(http://www.gnome.org), and Konqueror is the
manager/browser for the KDE desktop (http://www.kde.org). Both of these applications have an
explorer-level WebDAV client built-in, and they operate just fine
against an autoversioning repository.

In GNOME’s Nautilus, select the File→Open location menu item and enter
the URL in the dialog box presented. The repository should then be
displayed like any other filesystem.

In KDE’s Konqueror, you need to use the webdav:// scheme when entering the URL in
the location bar. If you enter an http:// URL, Konqueror will behave like an
ordinary web browser. You’ll likely see the generic HTML directory
listing produced by mod_dav_svn.
When you enter webdav://host/repos instead of
http://host/repos, Konqueror becomes a WebDAV
client and displays the repository as a filesystem.

WebDAV Filesystem Implementation

The WebDAV filesystem
implementation is arguably the best sort of WebDAV client. It’s
implemented as a low-level filesystem module, typically within the
operating system’s kernel. This means that the DAV share is mounted like
any other network filesystem, similar to mounting an NFS share on Unix
or attaching an SMB share as a drive letter in Windows. As a result,
this sort of client provides completely transparent read/write WebDAV
access to all programs. Applications aren’t even aware that WebDAV
requests are happening.

WebDrive, NetDrive

Both WebDrive and NetDrive are excellent commercial products that
allow a WebDAV share to be attached as drive letters in Windows. As a
result, you can operate on the contents of these WebDAV-backed
pseudodrives as easily as you can against real local hard drives, and
in the same ways. You can purchase WebDrive from South River
Technologies (http://www.southrivertech.com).
Novell’s NetDrive is freely available online, but it requires users to
have a NetWare license.

Mac OS X

Apple’s OS X operating system has an integrated filesystem-level WebDAV
client. From the Finder, select the Go→Connect to Server menu item. Enter a
WebDAV URL, and it appears as a disk on the desktop, just like any
other mounted volume. You can also mount a WebDAV share from the
Darwin terminal by using the webdav
filesystem type with the mount
command:

Note that if your mod_dav_svn
is older than version 1.2, OS X will refuse to mount the share as
read/write; it will appear as read-only. This is because OS X insists
on locking support for read/write shares, and the ability to lock
files first appeared in Subversion 1.2.

Also, OS X’s WebDAV client can sometimes be overly sensitive to
HTTP redirects. If OS X is unable to mount the repository at all, you
may need to enable theBrowserMatch directive in the Apache
server’s httpd.conf:

BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully

Linux davfs2

Linux davfs2 is a filesystem module for the Linux kernel, whose
development is organized at
http://dav.sourceforge.net/. Once you install
davfs2, you can mount a WebDAV network share using the usual
Linux mount command:

$ mount.davfs http://host/repos /mnt/dav

[61] WebDAV support was removed from Microsoft Access for some
reason, but it exists in the rest of the Office suite.