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

Re: DAV lock-token decisions. (please read)

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2005-01-19 20:04:44 CET

--On Wednesday, January 19, 2005 1:54 PM -0500 Greg Hudson
<ghudson@MIT.EDU> wrote:

> On Wed, 2005-01-19 at 13:13, Ben Collins-Sussman wrote:
>> And the use-case isn't absurd. There will definitely be corporate
>> users of Subversion who will want to disable concurrency altogether.
>> They'll keep their entire tree in a read-only "svn:needs-lock" state.
>> And when somebody needs to change the license on all 1000 files,
>> they'll lock all of them in a working copy, edit them, and 'svn
>> commit'.
>> Justin Erenkrantz made a good point in IRC: it's not really DAV that's
>> flawed here. A real DAV client would lock the whole directory and use
>> a single token for everything. But we decided to punt on
>> directory-locks, and in some sense we're now paying the price.
> Er, no. You *just* defined a use case where you'd want locks on all the
> files. "I want to disable concurrency altogether" would not mean using
> directory locks.

I'm not sure how you see that as requiring an individual lock on every
file. A WebDAV client takes a LOCK on the top-level directory with
infinite depth and that means that no files or sub-collections can be
modified without holding that lock first.

> I think we should totally give up on having our client act like a DAV
> client, and use custom reports whenever we have the slightest reason to
> do so. (Modulo compatibility issues, of course.) Our client will never
> work against a generic DAV server, so there's no value in it.

I disagree completely. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 20:06:05 2005

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.