Mark,
----- Original Message -----
From: "Mark O'Brien" <[EMAIL PROTECTED]>
>
> Okay, here's what I would like to do.
>
> Short: Create and automated baseline/build/package system, that executes
> after being given bugs that have been fixed.
>
> ...
> 1) Need to have CVS ask for bug number prior to checkin. Validate the number
> with the bug track tool, get the state of the bug and branch to be fixed on.
>
>
> 2) Either before or after checkin, somehow associate the validated bug
> number with the version of the file
I appreciate the direction you're heading with this effort. What I can contribute
is a set of CVS loginfo trigger scripts which provide automatic tagging of the
revision being checked in based on an SCR number indicated in the revision
log comment (specificaly, using the autotag.pl perl script). This has worked reliably
in "production" use for about 6 months using both local and pserver mode
(Solaris server, Solaris and NT clients).
The slightly nondeterministic aspect of the script is that it must actually run the
rtag
command after the commit is finished (so that the tag is applied to the new revision,
not the old revision.) To accomplish this, the the script spawns a background task
which waits a couple of seconds before the tag is applied. I have never seen this
fail to work, but it is an aspect of the script that could perhaps be tweaked to rely
on a different method to guarantee the correct revision number is tagged.
The tag is constructed using the project name (assumed to be the top-level
CVS repository directory), the branch name (if any), and the SCR number.
The rcsinfo template contains "SCR #:", which is the trigger which generates
the tag(s). The developer may indicate one or more SCRs delimited by space
or comma.
For example, let's say a developer is working from a checkout of the top-level
cvs repository directory "tools" from the trunk with a base revision 1.4. Upon
commit, the developer uses the revision comment:
SCR #: 56, 78
Fixed a bug relating to the widget subsystem.
Following commit, the tags "TOOLS_SCR_56" and "TOOLS_SCR_78" will
be applied to revision 1.5.
Let's say instead the developer was working from a branch checkout
("TOOLS_REL1_BRANCH") of the same project. Then the script would
use "TOOLS_REL1" rather than the repository directory as the project name,
resulting in the tags "TOOLS_REL1_SCR_56" and "TOOLS_REL1_SCR_78".
The script requires branches to be named according to the convention
"<branch_name>_BRANCH" for this to work.
If the same file is committed again with the same SCR number specified, the
tag(s) will be moved to the new revision being checked in.
No validation of the SCR number is performed (e.g. it doesn't check a file to
be sure the SCR number is present in a bug tracking tool), nor is a commit
rejected if an SCR number is not indicated. The commit rejection could be
handled separately (verifymsg).
This particular set of scripts requires no patching of the CVS 1.10 or 1.11 code.
I would be interested to see a final integrated set of triggers and/or CVS patches
which provide the functionality you describe...
Good luck,
David Martin
SCR #:
combolog.sh
loginfo
autotag.pl
