22, 2005, at 1:28 PM, Brian W. Fitzpatrick wrote:
I'd like to revisit the decision that came out of the "commit
and
unlock" discussion in December (Full thread here
http://svn.haxx.se/dev/archive-2004-12/0598.shtml).
The outcome of that thread was that 'svn commit' will unlock any file
that is specified as a target to 'svn commit' (including children of
directories).
What I think is apparent there, and not obvious in this
message, is that there are two completely different use cases tromping
around wearing the same name "lock." We are proposing to implement
only one of the two use cases, but that don't mean there ain't another
'un out there, somewhere.
Use case one has it that someone is making changes, or is just about
to make changes, to a file that ought not to be changed in parallel.
Never mind why that is, could range from "unmergeable data type" to
"company policy" to "sheer bloody-mindedness"; not important to us
here. The point is, the lock idea is attached to the intent-to-change.
Use case two has it that there's some file that shouldn't be changed
at all, or only by decree from God as interpreted by His Only Prophet
(say, me). Again, never mind why this is so, could range from
"there's some external contract related to this file's contents" to
"unmergeable data type" to "company policy" to "sheer
bloody-mindedness." The point is, the lock idea is attached to the
file itself.
In ClearCase (FWIW), these are, respectively, the "reserved checkout"
and the "lock." They're separate commands, and their effects are
different in just the sort of way Fitz raises here. The "reserved
checkout" (which may arise either as a side effect of the checkout
proper, or at any time after the checkout through a separate command,
"reserve") is automatically removed at checkin time (and can be
removed asynchronously with the "unreserve" command). The "lock" can
only be placed by the "lock" command, and can only be removed by the
"unlock" command. Either has the effect of preventing anyone else
from checking out the file. (Quibble 1: "check out" in ClearCase
doesn't mean what it does in CVS or Subversion (that's "update", just
like what we call "update"); rather, "check out" is an always (well,
nearly so) required step before making any changes. Quibble 2: other
people may still check out and modify the file if they create a
separate branch to work on, and indeed in some deep-voodoo sense, it's
really the branch tip that's "reserved," not the file or version
itself.)
I know that VSS provides "case one" behavior by default (indeed, I
think you have no choice about that); I dunno about case two.
CVS ... well, CVS does some rather different things, involving things
like email notification or extra commands just to check if someone
might actually have a lock set ... no doubt, in the spirit of that
great "C", concurrency, a spirit which we around here in some degree
applaud, but an implementation which, on the whole, we chose not to
imitate slavishly.
So in fact, what Fitz is raising is the question (in ClearCase
phraseology) "reserved checkouts, or locks?"
And I claim that that was, indeed, talked to screaming DEATH before,
and if the outcome wasn't clear, that was only because people had such
a hard time remembering that there are two different things here, and
we're only proposing (at least, for the moment) to implement one of
them. Oh, and also: because the one we most want, we can't do very
well, because there isn't any such "always (well, nearly so) required
step" as there is in ClearCase and VSS, so we're actually doing one
that feels kind off second-best.
I've read through the thread, and I can't say that I saw a
clear
comparison of the pros and cons of the various options presented, so
I'd like to open up this can of worms again and do some "information
gathering and aggregation."
The three options for *default* behavior that were presented are:
a) Upon commit, unlock all locked files in TARGETS
PROS: - Helps when you forget to unlock files when you're done with
them.
CONS: - If you want to make multiple commits to a file without
releasing a lock, you need to pass --no-unlock when
committing.
This is not about "helping." This is about "what is it
we're doing?" Model (a) removes the lock at commit because it should,
because (so says this model) the lock is a property of the
intent-to-change, and the change is completed with the commit.
Alternatives like "--no-unlock" are provided because models are always
more pure than reality, but they're options, not main-line behavior,
because they violate the model. The idea is, people should learn
subconsciously that "locks have to do with intent to change," and only
go hunting for a rule-breaker when they have a rule-breaking need.
b) Upon commit, unlock SOME locked files in TARGETS
PROS: - Makes it easier to divide separate commits into changesets.
CONS: - YASSC (Yet Another Subversion Special Case).
- Violates KISS.
I do not recall this case being discussed. I ask, in some
horror, "unlock *which* files????" My thought, in so asking, is not
that anyone has a good answer to the question, but rather that in
considering the question, everyone will realize what a truly monstrous
idea this really is ;-)
c) Upon commit, unlock nothing
PROS: - Avoids possible conflicts in unmergeable files that are left
unlocked (although svn:needs-lock alleviates this somewhat).
- Doesn't overload commit with locking behaviors.
CONS: - You can forget that they you have files locked and prevent
others from editing those files.
Ah, yes, the other model: there's something persistent about
the file that means it should always be locked. This is a simpler
model to understand than the first, and simpler to implement.
Can interested parties please contribute more pros and cons
to this
list? I'll summarize the discussion and post the total pros and cons
to the list.
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.
-==-
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