[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 Phippard <MarkP_at_softlanding.com>
Date: 2004-10-13 22:37:56 CEST

"Brian W. Fitzpatrick" <fitz@collab.net> wrote on 10/13/2004 04:30:59 PM:

> 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.
>
> Am I missing something?

Plus, we have established that you can only lock the youngest revision
anyway, or more specifically your WC has to have the youngest revision.

In PVCS, you create a branch by locking a non-HEAD revision. When you
check-in, that creates the branch at that revision. So, again in PVCS,
you can allow multiple locks on a file, but only one per revision. There
is also an option to only allow one lock on the entire file.

None of this of course applies to Subversion as it has a different
branching model. So, I agree, you would essentially acquire a lock on a
file, not a specific revision of a file. A lock in a branch would
essentially be a different file so different users could still lock the
same file in trunk and a branch.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 22:38:29 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.