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

Re: Locking UI comments

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-10-13 23:31:52 CEST

On Wed, Oct 13, 2004 at 03:30:59PM -0500, Brian W. Fitzpatrick wrote:
> On Wed, 2004-10-13 at 14:13, Justin Erenkrantz wrote:
> > --On Wednesday, October 13, 2004 1:22 PM -0400 Mark Benedetto King
> > <mbk@lowlatency.com> wrote:
> >
> > > I think it should be atomic, in the following way:
> > >
> > > Client -> Server
> > >
> > > LOCK /foo.c @ r1234
> > >
> > > Server -> Client
> >
> > FWIW, that won't mesh at all with WebDAV's LOCK model. In WebDAV, you just
> > lock the entire resource not a specific version. So, at the very least, if we
> > tried to lock a resource/version pair, we'd likely lock out most WebDAV
> > clients from participating. And, that'd be real bad, IMHO. -- justin
>
> I don't understand the utility of locking a path at a specific
> revision--you can't edit the contents of a revision.
>

That's not a peg notation, that's saying "I have revision 1234 of /foo.c and
I want to acquire a lock on /foo.c".

The response from the server is either "okay, here is your lock token"
or "sorry, that's not the youngest revision of /foo.c" or "sorry, something
else has gone wrong".

Blind LOCKing is something that a normal WebDAV client could do, but that
doesn't prevent us from supporting a LOCK request that does automatic and
atomic update-to-dateness checking; I don't think they're mutually
exclusive.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 23:32:13 2004

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.