WebDAV and Autoversioning

sions.

Is this fantasy real? Not quite. The main snag is that Subversion 1.0 has no support whatsoever for the WebDAV LOCK or UNLOCK methods. Most operating system DAV clients attempt to LOCK a resource opened directly from a DAV-mounted network share. For now, users may have to copy a file from the DAV share to local disk, edit the file, then copy it back again. Not ideal autoversioning, but still doable.

The mod_dav_lock Alternative

The mod_dav Apache module is a complex beast: it understands and parses all of the WebDAV and DeltaV methods, yet it depends on a back-end “provider” to access the resources themselves.

In its simplest incarnation, a user can use mod_dav_fs as a provider for mod_dav. mod_dav_fs uses the ordinary filesystem to store files and directories, and only understands vanilla WebDAV methods, not DeltaV.

Subversion, on the other hand, uses mod_dav_svn as a provider for mod_dav. mod_dav_svn understands all WebDAV methods except LOCK, and understands a sizable subset of DeltaV methods. It accesses data in the Subversion repository, rather than in the real filesystem. Subversion 1.0 doesn't support locking, because it would actually be quite difficult to implement, since Subversion uses the copy-modify-merge model.47

In Apache httpd-2.0, mod_dav supports the LOCK method by tracking locks in a private database, assuming that the provider is willing to accept them. In Apache httpd-2.1 or later, however, this locking support has been broken into an independent module, mod_dav_lock. It allows any mod_dav provider to take advantage of the lock database, including mod_dav_svn, even though mod_dav_svn doesn't actually understand locking.

Confused yet?

In a nutshell, you can use mod_dav_lock in Apache httpd-2.1 (or later) to create the illusion that mod_dav_svn is honoring LOCK requests. Make sure mod_dav_lock is either compiled into httpd, or being loaded in your httpd.conf. Then simply add the DAVGenericLockDB directive to your Location like so:

<Location /repos> DAV svn

SVNPath /absolute/path/to/repository SVNAutoversioning on DavGenericLockDB /path/to/store/locks

</Location>

This technique is a risky business; in some sense, the mod_dav_svn is now lying to the WebDAV client. It claims to accept the LOCK request, but in reality the lock isn't being enforced at all levels. If a second WebDAV client attempts to LOCK the same resource, then mod_dav_lock will notice and correctly deny the request. But there's absolutely nothing preventing an ordinary Subversion client from changing the file via a normal svn commit! If you use this technique, you're giving users the opportunity to stomp on each others' changes. In particular, a WebDAV client might accidentally overwrite a change committed by a regular Subversion client.

On the other hand, if you set up your environment very carefully, you may mitigate the risk. For example, if all of your users are working though basic WebDAV clients (rather than Subversion clients), then things should be fine.

Autoversioning Interoperability

In this section, we'll describe the most common generic WebDAV clients (at the time of writing), and how well they operate against a mod_dav_svn server using the SVNAutoversioning directive. RFC 2518 is a bit large, and perhaps a bit too flexible. Every WebDAV client behaves slightly differently, and creates slightly different prob-

47Subversion may someday develop a reserved-checkout locking model that can live peaceably with copy-modify-merge, but it probably won't happen soon.

271

WebDAV and Autoversioning

lems.

Win32 WebFolders

Windows 98, 2000, and XP have an integrated WebDAV client known as “WebFolders”. On Windows 98, the feature might need to be explicitly installed; if present, a “WebFolders” directory appears directly within My Computer. On Windows 2000 and XP, simply open My Network Places, and run the Add Network Place icon. When prompted, enter the WebDAV URL. The shared folder will appear within My Network Places.

Most write operations work fine against an autoversioning mod_dav_svn server, but there are a few problems:

•If a Windows XP computer is a member of an NT Domain, then it seems to be unable to connect to the WebDAV share. It repeatedly asks for a name and password, even when the Apache server isn't issuing an authentication challenge! If the machine isn't part of an NT Domain, then the share is mounted without a problem.

This problem seems to stem from changes in the way Windows XP creates WebFolder shortcuts ( .lnk files). It sometimes replaces the URL of the WebDAV share with a Windows “UNC” (Universal Naming Convention) path instead. This causes Explorer to attempt a connection using SMB instead of HTTP.

A workaround for this problem is to create the .lnk shortcut on a Windows 2000 computer and then copy this shortcut to the Windows XP computer. It would probably also be possible to “fix” the shortcut using a HEX editor, if one were to reverse-engineer the .lnk file format.

•A file can't be opened for direct editing from the share; it always comes up read-only. The mod_dav_lock technique doesn't help, because WebFolders doesn't use the LOCK method at all. The previously mentioned “copy, edit, re-copy” method does work, however. The file on the share can be successfully overwritten by a locally edited copy.

Mac OS X

Apple's OS X operating system has an integrated WebDAV client. From the Finder, select the “Connect to Server” item from the Go menu. Enter a WebDAV URL, and it appears as a disk on the desktop, just like any file server.48

Unfortunately, this client refuses to work against an autoversioning mod_dav_svn because of its lack of LOCK support. Mac OS X discovers the missing LOCK ability during the initial HTTP OPTIONS feature exchange, and thus decides to mount the Subversion repository as a read-only share. After that, no write operations are possible at all. In order to mount the repository as a read-write share, you must use the mod_dav_lock trick discussed previously. Once locking seems to work, the share behaves very nicely: files can be opened directly in read/write mode, although each save operation will cause the client to do a PUT to a temporary location, a DELETE of original file, and a MOVE of the temporary resource to the original filename. That's three new Subversion revisions per save!

One more word of warning: OS X's WebDAV client can be overly sensitive to HTTP redirects. If you're unable to mount the repository at all, you may need to enable the BrowserMatch directive in your httpd.conf:

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

Unix: Nautilus 2

In general, Nautilus 2 works reasonably well against an autoversioning mod_dav_svn, with the following caveats:

48Unix users can also run mount -t webdav URL /mountpoint.

272

WebDAV and Autoversioning

•Any files opened directly from the share are treated as read-only. Even the mod_dav_lock trick seems to have no effect. It seems that Nautilus never issues the LOCK method at all. The “copy locally, edit, copy back” trick does work, however. Unfortunately, Nautilus overwrites the old file by issuing a DELETE first, which creates an extra revision.

•When overwriting or creating a file , Nautilus first does a PUT of an empty file, then overwrites it with a second PUT. This creates two Subversion filesystem revisions, rather than one.

•When deleting a collection, it issues an HTTP DELETE on each individual child instead of on the collection itself. This creates a whole bunch of new revisions.

Linux davfs2

Linux davfs2 is a filesystem module for the Linux kernel, whose development is located at http://dav.sourceforge.net/. Once installed, a WebDAV network share can be mounted with the usual Linux mount command.

The word on the street is that this DAV client doesn't work at all with mod_dav_svn's autoversioning. Every single attempt to write to the server is preceded by a LOCK request, which mod_dav_svn doesn't support. At this time, there is no data indicating whether the use of mod_dav_lock resolves this problem.

273