On Feb 22, 2005, at 5:32 PM, 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.
I'll defer to Branko in summarizing the consensus. And I am
not advocating any position in any thing I say here, only trying to
clarify consensus (maybe not succeeding very well, a different
problem).
But I think, maybe, that Branko's fingers got ahead of his thoughts
here. Expanding his comment a bit, I think he means:
But but but ... [(c)] 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" idoim [that
is, Fitz's (a)]. This [(c)] is what the svn:needs-lock property means.
But you should note that my descriptions included "unmergeable data
type" in both use cases, and hence "protect against parallel changes."
I think the data-type case straddles the line. As an example that's
in some ways clearer, I've seen message catalogs handled in locking
style, because the organization felt a need to have one message
catalog for all versions of the software. I'm talking, here, about a
catalog that maps an error number to a message, not particularly a
catalog used for translations, although they used it for that, too.
The point was, if you debug a program against version 6.3.5 and learn
that error number -1437 means "You didn't stand on your head when you
did that," then that same number has to mean that same error later,
when you port your program to version 8.9.10.11. That, first of all,
means they didn't branch the error code file even though they did
branch the code; second, it means that the documentation people need
to be involved in any changes (need to add new codes to the books,
which were actually, gasp, printed on paper before the users could
see them). And in this organization, they felt the only way to make
that all happen was to make the message file owned by a Committee that
met monthly and wrangled endlessly over new messages and their
numbers. (Personally, I don't agree that's the only, or even best,
way to do this, but they never offered to make me God. But now I've
got back at them by calling that whole mess "sheer bloody-mindedness"!
;-)
In the fitzological terminology, that's (c): they had a locking need
related to the file, not to any one change. The files themselves were
mere text, they could have been merged (or at least, any merge tool in
the land would have thought it could merge them). But the
organization had decided the files were unmergeable, and indeed that
you needed a special place in the org-chart in order to change the
file at all.
Contrast, some organizations live most of their lives without any
locking/reservations/whatever, but institute a restrictive policy as
the release nears. That makes the need for lock a property of the
change (any change happening during that time).
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",
Oooh, you're right about me, at least: "lock the wc vs. lock
the URL" is a useful way of distinguishing the two use cases. Thanks
for the reminder!
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org