|
From: | David L. Martin |
Subject: | Automatic tagging using revision log message (was Re: 2 "how to <> in CVS" questions) |
Date: | Sat, 17 Feb 2001 16:41:09 -0600 |
Mark, ----- Original Message ----- From: "Mark O'Brien" <address@hidden> > > 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
rcsinfo_template.txt
Description: Text document
combolog.sh
Description: Binary data
loginfo
Description: Binary data
autotag.pl
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |