httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@Fujitsu-Siemens.com>
Subject [PATCH] Freezing/locking a cvs tree for release maintenance
Date Tue, 27 Feb 2001 20:50:17 GMT
Hello committers / release managers!

You have often experienced the tar ball release scenario,
when the RM tries to get the stable tree out as a release
candidate, but then someone commits in the last few minutes!

Now imagine the following scenario:

% cvs commit -m "Commit one final patch before RM rolls the tarball"
==============================================================
ERROR: The apache-1.3 CVS tree is locked for maintenance!

       Commits/Tags are currently only allowed for users:
         jim

In urgent cases, ask one of these committers to release the lock.
==============================================================
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!
Exit 1


or with a TAG which is about to be applied:

% cvs tag foobar
==============================================================
ERROR: The apache-1.3 CVS tree is locked for maintenance!

       Commits/Tags are currently only allowed for users:
         jim
	 gstein

In urgent cases, ask one of these committers to release the lock.
==============================================================
cvs server: Pre-tag check failed
cvs [server aborted]: correct the above errors first!
Exit 1

Instead of "apache-1.3", you can lock any repository, and instead
of "jim" or "gstein", you can have any RM's user id.
(In fact, every committer could set a lock...)

The script which is attached solves (for me, at least) the fear that
unwanted commits or taggings can influence the release. Simply set a
lock when you freeze the tree, and remove the lock after the release.

For the release manager, it looks like this:

  % cvs checkout apache-1.3        # pull whole tree
  % cd apache-1.3                  # and inside, create a .frozen file
  % echo ${USER} >.frozen          # with the release manager's id.
  % cvs add .frozen                # we assume no lock is there yet.

The critical region starts here:

  % cvs commit -m "Lock" .frozen   # from now on, we have control.

  ... edit httpd.h, commit, tag, roll etc...

  % cvs rm -f .frozen              # Finally, delete the .frozen file

The critical region ends after the following commit:

  % cvs commit -m "Unlock" .frozen # and allow free commits again

If, during the "critical region", another committer must be
granted access, you simply add her to the .frozen file:

  % echo sally >>.frozen           # sally may commit as well.
  % cvs commit -m "Add Sally" .frozen

You can never lock yourself out: the script checks this.


Of course, enough karma to install the script is required (once),
but after that, it sits in the background and does nothing, unless
a lock file (.frozen or whatever) appears at the base of the tree
which is under control of the script. And cvs allows flexible control
over the repositories which should be checked for locks.

The administrator only needs to do the following to activate it (once):

  % cvs checkout CVSROOT           # Get cvs administrative files
  % cd CVSROOT
  % cp ...../check-frozen .        # Add this script.
  % chmod 755 check-frozen         # Make script executable
  % cvs add check-frozen           # Add to CVSROOT repository
  % echo check-frozen >>checkoutlist # Add to administrative files
  % echo '^apache-1.3/?  /home/cvs/CVSROOT/check-frozen commitinfo' >>commitinfo
  % echo '^apache-1.3/?  /home/cvs/CVSROOT/check-frozen taginfo' >>taginfo

Replace "apache-1.3" by your cvs repository name in the lines above,
and invoke an editor instead of adding the line with "echo >>".
Finally, commit all changed files to enable lock ckecking:

  % cvs commit -m "Add .frozen lock support to apache-1.3" \
         check-frozen checkoutlist commitinfo taginfo

That's it. Try it on your own CVS roots at home, and tell me whether
we should use it on apache.org

I checked it both with :pserver: and /home/cvs (local) repositories.
I expect :ext: to be exactly like local.

    Martin
-- 
<Martin.Kraemer@Fujitsu-Siemens.com>    |       Fujitsu Siemens
       <martin@apache.org>              |   81730  Munich,  Germany

Mime
View raw message