>--- Forwarded mail from [EMAIL PROTECTED] >On Mon, 26 Aug 2002, Pat Young wrote:
>> Date: Mon, 26 Aug 2002 14:12:04 -0700 (PDT) >> From: Pat Young <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
