Re: Locking a branch

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Mon, 26 Aug 2002, Pat Young wrote:

>> Date: Mon, 26 Aug 2002 14:12:04 -0700 (PDT)
>> From: Pat Young <address@hidden>
>> To: address@hidden
>> Subject: [info-cvs] Locking a branch
>> 
>> What is the best way to lock a branch?  Should I use

>How about:

>``Please don't commit to this branch until told otherwise, or you
>will be fired on grounds of inability to follow instructions.''

>Why work with people that require a piece of software to stop them from
>doing what they aren't supposed to?

Everybody makes mistakes.  Good tools warn people when they're about to
do something bad.

>In any case, even if you had a way to do it, you would still want to
>send out a notice, so that people can organize their work according to
>the newly imposed restriction, rather than run into it when they
>attempt to commit some completed work.

This goes without saying.

>> the admin -l option?  I tried this and couldn't get it
>> to work.  I have also seen some previous post
>> suggesting to create a #commitinfo file.  We would
>> like to be able to lock a complete branch, so that
>> developers can not accidentally commit changes to the
>> branch.  Any help would be greatly appreciated.

>Make a tag on the branch. That tag will identify the baseline that you
>care about, regardless of any subsequent commits.  (A better question
>would be, how to lock some tags so they can't be deleted or moved!
>The answer is you can't).

I think you misunderstand the goal here.  Normally when a development
branch reaches a critical state, there's a desire to control very carefully
what gets committed on it.  Sometimes people try to sneak something in
quietly at the last minute, sometimes they're frazzled and use the wrong
sandbox and try to commit a change in the wrong place.  Sometimes commits
are fine, provided something else (e.g. a valid and approved ECO number) is
needed.  And sometimes you want one group of people (e.g. development
engineers) to commit to different branches than others (e.g. maintenance
engineers).  And sometimes you want to apply different policies to
different branches (e.g. ECO numbers required on the trunk, all others
are wide open).  And sometimes you really want to disallow commits
(e.g. releases that have past their end of life milestone).

All of these legitimate policies limit the commit capability in some way or
another, and none of them cause tags to be deleted or moved.  And many
shops, especially large ones, require some form of mechanical enforcement
of their policies in addition to management directive to the masses.

>Locking files against commits just doesn't make sense in a version
>control system, because old versions are not destroyed by new
>versions.

The question was not about locking files; it was about locking branches.
These are two different things.  It's usually legitimate and desirable to
permit commits on some branches.  It's also usually legitimate and desirable
to prohibit commits on some branches.  That's not the same thing as
locking files so that no one can commit any change to them.

>In effect, a commit operation is a function that takes a repository and
>returns a new repository with added material.

>A branch is created so that the users have an appropriate place for
>certain kinds of commits. If you could lock a branch, you would take
>away the reason for its existence.

Not at all.  You provide a means to preserve it for special purposes.
Remember, "locking" isn't necessarily permanent; locks can be removed and
replaced as needed.  Good systems provide selective locks that permit
access to some users and not to others.

>--- End of forwarded message from address@hidden