[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: Greg Stein <gstein_at_lyra.org>
Date: 2005-01-19 20:42:41 CET

On Wed, Jan 19, 2005 at 11:04:44AM -0800, Justin Erenkrantz wrote:
> --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'.

Also note that you can do partial commits to work around the problem.
Sub-optimal as it breaks up your logical change across commits, but it
is possible.

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

Agreed. Directory locks avoids the problem quite easily.

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

Same. I can *easily* see a time when we could 'svn co' from any old
DAV server. In fact, the original code *could* do that, but we moved
to a report for performance purposes (lack of HTTP pipelining). When
we get a pipelining library, then I fully expect that we could switch
back to a series of PROPFIND/GET requests to do the checkout.

Commits? Our commit process *does* look like what a DeltaV server
would support. We ought to be able to do a commit, too. And somebody
implementing a DeltaV server would probably be looking at the svn
client for compatibility. (what other client would they use?)


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 Wed Jan 19 20:38:37 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.