(cvs.info.gz) verifymsg
Info Catalog
(cvs.info.gz) commitinfo
(cvs.info.gz) Trigger Scripts
(cvs.info.gz) loginfo
C.3.5 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
( rcsinfo).
The `verifymsg' file has the standard form for script hooks (
Trigger Scripts), where each line is a regular expression followed by
a command to execute. It supports only the DEFAULT keywords.
In addition to the common format strings ( syntax),
`verifymsg' supports:
l
the full path to the file containing the log message to be verified
Currently, if no format strings are specified, a default string of `
%l' will be appended to the command line template before replacement is
performed, but this feature is deprecated. It is simply in place so
that legacy repositories will remain compatible with the new CVS
application. For information on updating, Updating Commit
Files.
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 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.
config, 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.
Menu
* verifymsg example Verifymsg example
Info Catalog
(cvs.info.gz) commitinfo
(cvs.info.gz) Trigger Scripts
(cvs.info.gz) loginfo
automatically generated byinfo2html