RE: How to lock CVS for check-in

[Greg A. Woods]

[ 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      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>