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