O'Reilly    
 Published on O'Reilly (http://oreilly.com/)
 See this if you're having trouble printing code examples


WebDAV and Autoversioning - Version Control with Subversion

by Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato

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.

Version Control with Subversion book cover

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.

buy button

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_svn could 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.conf Location block, like so:

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

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:

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on

  ModMimeUsePathInfo on

</Location>

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.

Table C.1. Common WebDAV clients

SoftwareTypeWindowsMacLinuxDescription
Adobe PhotoshopStandalone WebDAV applicationXImage editing software, allowing direct opening from and writing to WebDAV URLs
cadaverStandalone WebDAV applicationXXCommand-line WebDAV client supporting file transfer, tree, and locking operations
DAV ExplorerStandalone WebDAV applicationXXXJava GUI tool for exploring WebDAV shares
Adobe DreamweaverStandalone WebDAV applicationXWeb production software able to directly read from and write to WebDAV URLs
Microsoft OfficeStandalone WebDAV applicationXOffice productivity suite with several components able to directly read from and write to WebDAV URLs
Microsoft Web FoldersFile-explorer WebDAV extensionXGUI file-explorer program able to perform tree operations on a WebDAV share
GNOME NautilusFile-explorer WebDAV extensionXGUI file explorer able to perform tree operations on a WebDAV share
KDE KonquerorFile-explorer WebDAV extensionXGUI file explorer able to perform tree operations on a WebDAV share
Mac OS XWebDAV filesystem implementationXOperating system that has built-in support for mounting WebDAV shares
Novell NetDriveWebDAV filesystem implementationXDrive-mapping program for assigning Windows drive letters to a mounted remote WebDAV share
SRT WebDriveWebDAV filesystem implementationXFile transfer software, which, among other things, allows the assignment of Windows drive letters to a mounted remote WebDAV share
davfs2WebDAV filesystem implementationXLinux 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:

$ cadaver http://host/repos
dav:/repos/> ls
Listing collection '/repos/': succeeded.
Coll: > foobar                                 0  May 10 16:19
      > playwright.el                       2864  May  4 16:18
      > proofbypoem.txt                     1461  May  5 15:09
      > westcoast.jpg                      66737  May  5 15:09

dav:/repos/> put README
Uploading README to '/repos/README':
Progress: [=============================>] 100.0% of 357 bytes succeeded.

dav:/repos/> get proofbypoem.txt
Downloading '/repos/proofbypoem.txt' to proofbypoem.txt:
Progress: [=============================>] 100.0% of 1461 bytes succeeded.

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:

$ mount -t webdav http://svn.example.com/repos/project /some/mountpoint
$

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 the BrowserMatch 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.

If you enjoyed this excerpt, buy a copy of Version Control with Subversion.

Copyright © 2009 O'Reilly Media, Inc.