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