(cvs) verifymsg

Info Catalog

(cvs) commitinfo

(cvs) commit files

(cvs) editinfo

 
 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.
 
     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.
 
    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 head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
          exit 0
      elif head -1 < $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
 

Info Catalog

(cvs) commitinfo

(cvs) commit files

(cvs) editinfo