On Wed, 2005-02-23 at 02:32 +0100, Branko Čibej wrote:
> 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).
OK. It seems apparent to me that the (a) crowd is in the majority
here.
I'll stop bringing this up and go fix the bug where running 'svn commit'
on a working copy with no local mods (but with lock tokens) currently
creates a revision with no changes (and unlocks all the TARGETS that
have lock tokens).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 24 21:40:15 2005