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