[ 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
