Re: Locking a branch

[Mark D. Baushke]

Douglas Finkle writes:
> > > Some time ago John Cavanaugh wrote a patch for commit.c,
> > > but I don't think it was ever incorporated-- don't know why.
> 
> Perhaps since this patch is more than 3 years old it could be time
> to revisit this? (ground swell beginning now.... ;-)

I do not see a strong incentive to burden cvs with a particular set of
policy choices.

It is not difficult to implement a policy for your own needs and using
the existing the commitinfo infrastructure.

What we do here is have a cvsadmin module which contains a adminlock
file that is branched identically with our normal modules. Our
particular policy is that the lack of an adminlock means that it is not
controlled and commits are permitted.

We were already parsing the CVS/Entries file to ensure that folks didn't
mix branches on their commits by accident, so using that same branch tag
to do a

   cvs $CVSROOT co -p -r$tag cvsadmin/locks/adminlock

and then processing this output to determine if the branch was locked or
not for this particular user on this particular branch is not that hard
to do.

If you wanted something to permit/deny based on a particular defect-id
in the log message, then you could add it to the verifymsg processing.

In a similar manner, you could use the same method to deal with the
taginfo script if needed. It all depends on what policy you want to
adopt and determine if it varies across branches and modules or with
defect-id or userid or any other criteria you may need for your
particular situation.

        -- Mark