This section deals with best practices for CVS server side setup and configuration.
One of the important questions that I have been asked time and again is the ability to have access control for files/folders/branches etc., within the CVS repository for various users. Unfortunately CVS does not come with a built in Access control capability but it does support a rudimentary form of access control through the readers/writers files in the CVSROOT repository. I have put together a set of scripts that use the readers/writers files to provide a slightly useable version of access control. This is available at http://cvspermissions.sarovar.org as an Open Source project. Feel free to use it and let me know how it works for you.
Server side scripting refers to the ability to make CVS server execute certain scripts when an event occurs. A common script that helps is to verify that all cvs commits contain acomment entered by the developer. The process involves setting up the CVSROOT/verifymsg file to run a script when a file is checked-in.
------CVSROOT/verifymsg---------
#Set the verifymsg file to fire a script
DEFAULT /usr/local/bin/validate-cvs-log.sh
------/usr/local/bin/validate-cvs-log.sh ---------
#!/bin/sh
#
# validate-cvs-log.sh logfile
# test that log message has some characters in it
if [ `cat $1 | wc -c ` -lt 10 ] ; then
echo "log message too short; please enter a description for the changes"
exit 1
else
exit 0
fi
|
The CVS server can be configured to notify through e-mails in case of a commit happening. This can be used to verify whether commits are occurring during the course of a daily/release build. If such commits occur, based on the project policy, the commits can be ignored or the entire build automatically restarted.