head	1.3;
access;
symbols;
locks; strict;
comment	@# @;


1.3
date	2004.06.09.19.09.31;	author rse;	state Exp;
branches;
next	1.2;

1.2
date	2000.06.13.09.18.36;	author ossp;	state Exp;
branches;
next	1.1;

1.1
date	2000.06.13.09.11.07;	author ossp;	state Exp;
branches;
next	;


desc
@@


1.3
log
@upgrade to OSSP shiela 1.1.2 and CVS 1.12.x
@
text
@##
##  CVSROOT/verifymsg -- post-edit hooking
##  Copyright (c) 2000 Ralf S. Engelschall <rse@@engelschall.com>
##

#   This file is used to allow verification of logging information. It works
#   best when a template (as specified in the $CVSROOT/CVSROOT/rcsinfo file)
#   is provided for the logging procedure. Given a template with locations
#   for, a bug-id number, a list of people who reviewed the code before it can
#   be checked in, and an external process to catalog the differences that
#   were code reviewed, the following test can be applied to the code: 1.
#   Making sure that the entered bug-id number is correct. 2. Validating that
#   the code that was reviewed is indeed the code being checked in (using the
#   bug-id number or a seperate review number to identify this particular code
#   set.). If any of the above test failed, then the commit would be aborted.
#   Actions such as mailing a copy of the report to each reviewer are better
#   handled by an entry in the loginfo file. One thing that should be noted is
#   the the ALL keyword is not supported. There can be only one entry that
#   matches a given repository.

DEFAULT $CVSROOT/CVSROOT/shiela --hook=verifymsg %l

@


1.2
log
@Initial CVSROOT contents
@
text
@d21 1
a21 3
#DEFAULT $CVSROOT/CVSROOT/logcheck

DEFAULT $CVSROOT/CVSROOT/shiela --hook=verifymsg
@


1.1
log
@initial checkin
@
text
@d1 24
a24 21
# The "verifymsg" file is used to allow verification of logging
# information.  It works best when a template (as specified in the
# rcsinfo file) is provided for the logging procedure.  Given a
# template with locations for, a bug-id number, a list of people who
# reviewed the code before it can be checked in, and an external
# process to catalog the differences that were code reviewed, the
# following test can be applied to the code:
#
#   Making sure that the entered bug-id number is correct.
#   Validating that the code that was reviewed is indeed the code being
#       checked in (using the bug-id number or a seperate review
#       number to identify this particular code set.).
#
# If any of the above test failed, then the commit would be aborted.
#
# Actions such as mailing a copy of the report to each reviewer are
# better handled by an entry in the loginfo file.
#
# One thing that should be noted is the the ALL keyword is not
# supported.  There can be only one entry that matches a given
# repository.
@