Welcome
Welcome to <strong>The Linux And Unix Menagerie</strong>.

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. Registration is fast, simple, and absolutely free, so please, <a href="/profile.php?mode=register">join our community today</a>!

CVS Tags and forcing comments

New sub-forums will be spawned as content is added. Everything that doesn't belong somewhere else will stay here :)

CVS Tags and forcing comments

Postby yahoozer on Tue Mar 25, 2008 11:09 pm

Yo,

Does anyone know how to force people to log their cvs checkins/checkouts? I've got it set up to make vi come up whenever a user checks in or checks out source, but they can just escape out and not leave a comment.

Any thoughts? If there's a way to make it so a user has to put in the date and a description (And not an empty one) would anyone here know how to do that, or if it's even possible?


Thanks!

Yaz
yahoozer
 
Posts: 9
Joined: Sun Oct 28, 2007 4:40 pm

Postby laum on Thu Mar 27, 2008 10:24 pm

Hey There,

I didn't know if you could do this (or, if you could, how you could force someone to not just enter garbage text), but I found this on the CVS Online Wiki

Hope this helps :)

C.4.2 Verifying log messages
Once you have entered a log message, you can evaluate that message to check for specific content, such as a bug ID. Use the `verifymsg' file to specify a program that is used to verify the log message. This program could be a simple script that checks that the entered message contains the required fields.

The `verifymsg' file is often most useful together with the `rcsinfo' file, which can be used to specify a log message template.

Each line in the `verifymsg' file consists of a regular expression and a command-line template. The template must include a program name, and can include any number of arguments. The full path to the current log message template file is appended to the template.

One thing that should be noted is that the `ALL' keyword is not supported. If more than one matching line is found, the first one is used. This can be useful for specifying a default verification script in a directory, and then overriding it in a subdirectory.

If the repository name does not match any of the regular expressions in this file, the `DEFAULT' line is used, if it is specified.

If the verification script exits with a non-zero exit status, the commit is aborted.

In the default configuration, CVS allows the verification script to change the log message. This is controlled via the RereadLogAfterVerify CVSROOT/config option.

When `RereadLogAfterVerify=always' or `RereadLogAfterVerify=stat', the log message will either always be reread after the verification script is run or reread only if the log message file status has changed.

See section The CVSROOT/config configuration file, for more on CVSROOT/config options.

It is NOT a good idea for a `verifymsg' script to interact directly with the user in the various client/server methods. For the pserver method, there is no protocol support for communicating between `verifymsg' and the client on the remote end. For the ext and server methods, it is possible for CVS to become confused by the characters going along the same channel as the CVS protocol messages. See Remote repositories, for more information on client/server setups. In addition, at the time the `verifymsg' script runs, the CVS server has locks in place in the repository. If control is returned to the user here then other users may be stuck waiting for access to the repository.

This option can be useful if you find yourself using an rcstemplate that needs to be modified to remove empty elements or to fill in default values. It can also be useful if the rcstemplate has changed in the repository and the CVS/Template was not updated, but is able to be adapted to the new format by the verification script that is run by `verifymsg'.

An example of an update might be to change all occurrences of 'BugId:' to be 'DefectId:' (which can be useful if the rcstemplate has recently been changed and there are still checked-out user trees with cached copies in the CVS/Template file of the older version).

Another example of an update might be to delete a line that contains 'BugID: none' from the log message after validation of that value as being allowed is made.

The following is a little silly example of a `verifymsg' file, together with the corresponding `rcsinfo' file, the log message template and an verification script. We begin with the log message template. We want to always record a bug-id number on the first line of the log message. The rest of log message is free text. The following template is found in the file `/usr/cvssupport/tc.template'.

BugId:



The script `/usr/cvssupport/bugid.verify' is used to evaluate the log message.

#!/bin/sh
#
# bugid.verify filename
#
# Verify that the log message contains a valid bugid
# on the first line.
#
if sed 1q < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
exit 0
elif sed 1q < $1 | grep '^BugId:[ ]*none$' > /dev/null; then
# It is okay to allow commits with 'BugId: none',
# but do not put that text into the real log message.
grep -v '^BugId:[ ]*none$' > $1.rewrite
mv $1.rewrite $1
exit 0
else
echo "No BugId found."
exit 1
fi



The `verifymsg' file contains this line:

^tc /usr/cvssupport/bugid.verify



The `rcsinfo' file contains this line:

^tc /usr/cvssupport/tc.template



The `config' file contains this line:

RereadLogAfterVerify=always




, laum
laum
Site Admin
 
Posts: 46
Joined: Sun Oct 14, 2007 7:04 pm


Return to General Linux

Who is online

Users browsing this forum: No registered users and 0 guests

cron