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

Re: [Locking] commits and unlock (revisited)

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-02-23 02:32:38 CET

Jack Repenning wrote:

> The upshot I recall was (keyed to your alternatives):
> (a) This is the "the need for lock is a property of the change" model.
> Unfortunately, we can't do it well (due to lack of preexisting
> always-(well-nearly)-required please-let-me-edit step). Let's sigh a
> small sigh and not do this.
> (b) Insanity.
> (c) This is the "the need for lock is a property of the file" model.
> We can do this well. It covers the most-often cited use cases (files
> whose data cannot be merged, and users whose minds cannot grasp
> merge). Let's do this one.

But but but... this is not what our idea of locking is about at all.
What we /want/ to do is to allow people to lock files to protect against
parallel changes -- exactly the "need for lock is a property of the
change" model, or ClearCase's "reserved check-out" idiom. This is
exactly what the svn:needs-lock property means. I think it would be most
confusing if the property said one thing, but the behaviour of "svn
commit" said something else.

And we can have an equivalent of ClearCase's "lock" idiom, too, at no
extra cost. I think we're all forgetting that, in case (a), "svn commit"
would only unlock files _that had been locked in the same working copy_.
So if you do a "svn lock URL", the working copy knows nothing about the
lock, and "svn commit" won't touch the lock on the file (unless it's
been modified locally, in which case the commit will fail since the WC
doesn't contain the lock token anyway).

How this interacts with lock token discovery is another question.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 02:34:03 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.