[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 Hudson <ghudson_at_MIT.EDU>
Date: 2003-01-04 01:09:27 CET

On Fri, 2003-01-03 at 18:58, Ben Collins-Sussman wrote:
> Yes. They get a guarantee that they're not accidentally overwriting
> somebody's changes, and a guarantee that nobody will overwrite their
> own changes via some race condition.

Well, not really. In Linux davfs, for instance, you will still
overwrite my work if:

  I read the file
  You read the file
  I write out my edits
  You write out your edits

It doesn't matter that locks were used during the write operations; I
would need to acquire a write lock (with fcntl or flock or whatever)
before I read the file. I would expect a lock to fail (with ENOLCK or
some such) on a server with no locking support, but I don't see a reason
to disable writing entirely.

> But remember, these paranoid dav clients are using LOCK because
> they're not living in a versioned world. They fear that data could be
> permanently lost by accidental stomping.

I don't think that's necessarily true. And even if it is true, there
will be other clients which use LOCK for important purposes.

> So yes, we'd be lying, but with very little real impact. Just an
> ethical problem in my mind. :-)

It may seem like an ethical problem now, but it will become a technical
problem in the future. Knowing that there are servers out there which
lie about locks, clients may start to test that locks actually work. We
might extend our little white lie to falsify those clients' test
results. The de facto protocol starts to become more complicated and
more divergent from the paper specification. Cats and dogs, living
together. Total chaos.

> I guess it comes down to the question: it the little white lie worth
> it, if it means that all OSes can now mount repositories as
> read/write? It's a tradeoff to consider.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 4 01:10:17 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.