ac4bd338c8
plus a couple of minor changes.. Some highlights of the new stuff that was not in the old version: - remote access support.. full checkout/commit/log/etc.. - much improved dead file support.. - speed improvements - better $CVSROOT handling - $Name$ support - support for a "cvsadmin" group to cut down rampant use of "cvs admin -o" - safer setuid/setgid support - many bugs fixed.. :-) - probably some new ones.. :-( - more that I cannot remember offhand..
33 lines
1.4 KiB
Plaintext
33 lines
1.4 KiB
Plaintext
#
|
|
#ident "@(#)cvs/examples:$Name: $:$Id: editinfo,v 1.2 1995/11/14 23:30:07 woods Exp $"
|
|
#
|
|
# The "editinfo" 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.
|
|
#
|
|
# Although these test could be handled by an interactive script being
|
|
# called via an entry in commitinfo, The information reported in
|
|
# such a script can't be easily merged into the report.
|
|
#
|
|
# 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.
|
|
#
|
|
# Note there is no "edit" example script currently available....
|
|
#
|
|
DEFAULT $CVSROOT/CVSROOT/edit "%s"
|