[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Adding a no-op LOCK to mod_dav_svn

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-01-04 00:41:59 CET

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> But, we can't use the autoversioning stuff with Mac OS X (and some
> other DAV clients) until we at least appear to support LOCK.

Yes, apparently when mod_dav_svn sends "DAV: 1" instead of "DAV: 1, 2"
in the OPTIONS header response, OS X automatically mounts the volume
as read-only. ("You can't do locking? No writing then!")

And linux davfs *refuses* to do any writes at all (PUT, COPY, MOVE)
without first issuing a LOCK. It's overly paranoid.

> Perhaps we make it optional (i.e. have to use an httpd directive to
> enable this). If the directive is 'off,' we return with LOCK not
> implemented (or tweak mod_dav to return just DAV level 1 rather than
> adding level 2). But, if it is 'on,' we'll accept the LOCK method,
> but not do anything with it (or bare minimum required to keep the
> protocol happy). It'd be the responsibility of the administrator to
> realize that we're not doing anything with LOCK ops.

It could just be part of 'SVNAutoversioning on'. No need to create a
whole new directive.

The danger here is that if we always return 200 for LOCK/UNLOCK, then
dav clients will think they've locked a resource, when they haven't.
There's a risk that when they PUT, they'll accidentally overwrite
somebody else's work.

But then again, that's true with a normal, non-versioning file server
too. So it doesn't seem like a tragedy to me. (In fact, unlike a
normal file server, the old version isn't really gone forever!)

Considering that our deltaV-autoversioning support is only
incremental, I'd argue that this idea is the next logical baby-step in
our support. It will certainly fix our client problems in the
short-term, with no big negative effects.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 4 00:44:42 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.