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