[ On Thursday, October 11, 2001 at 15:14:47 (-0700), Pyatt, Scott wrote: ] > Subject: RE: How to lock CVS for check-in > > I don't know your environment, but branch locking is a common mechanism > for allowing read-only access to a branch.
Wel, "DUH!" :-) > It's really quite useful > and given the high frequency that this issue pops up in this forum, I'm > not alone in my view. I think the right phrase would be: "not alone in your confusion". > I'm not knocking CVS. Nor am I knocking anyone > who finds no use in it. But in companies that have a sizable > development team, especially one that's globally dispersed, and need to > many support back releases, branch locking provides a good solution. Do you have any idea how big the three main *BSD projects are, how widely diverse and dispersed their committers are? They seem to do well enough without branch locking. > Regardless of your SCM needs, there are many of us that would be better > off having branch locking as a standard feature in CVS. More likely it`s: "many of you need to learn more about employing external process controls".... > If adding some > form of branch locking directly or indirectly (e.g., changing the > interface to commitinfo) causes other problems, I'll live without it, > add a kludge or move to a tool that supports it. I'm okay with those > choices, IF there is a technical reason for CVS to not support branch > locking. El-cheap-o branch locking is not hard to hack on with commitinfo. That's about as far as it needs to go I think.... > You say that it solves the wrong problem. Given an example from my day > yesterday, a developer was swapping between a couple of workspaces to > compare what gets built in a release that is to ship in a few months > with one that shipped months back. She accidentally checked in part of > a new feature in a back release. Hey, she's human and fifteen minutes > later I had the problem fixed. Our organization is large enough that > this is a common problem, not because of one or two idiots, but because > of the shear number of developers, with differing levels of experience, > and number of branches, this problem keeps popping up. I don't see the problem here. You've apparently already got very effective external process controls. No disaster resulted. Your process prevailed. Remember: CVS is not a substitute for management. CVS is not a substitute for developer communication. CVS does not have change control CVS does not have a builtin process model You can build these things atop/around CVS -- i.e. use CVS as a component in a larger system. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs