[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: Greg Stein <gstein_at_lyra.org>
Date: 2003-01-04 01:00:12 CET

On Fri, Jan 03, 2003 at 05:41:59PM -0600, Ben Collins-Sussman wrote:
> 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.

Not at all. If somebody has a LOCK, then they'll get refused. This proposal
would silently perform the overwrite.

If you don't enforce the lock, then you're outright lying to the client and
just asking for trouble.

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

No, it isn't a baby-step. The autoversioning provides *valid* behavior in a
DAV-compatible fashion. This new proposal is changing this in a way that can
silently chew up people's work.

And note: people might not even notice. For example, you're using Microsoft
Office to save docs right to the server. We won't be seeing diffs, just some
binary changes. There won't be any way to detect that two people starting
work with rev 101, yet rev 103 overwrote changes that were made in rev 102.

No... I don't think this is a good thing to do. If we're going to respond to
a LOCK request, then we should respond properly to other locking features.


Greg Stein, http://www.lyra.org/
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:59:25 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.