Dave Horner's Website - Yet another perspective on things...
162 guests
Rough Hits : 3068654

### More from me...

how did u find my site?

what's a matter

Action expresses priorities.
--Mohandas Gandi
\begin{bmatrix} 1 & 0 & \ldots & 0 \\ 0 & 1 & 0 & \vdots \\ \vdots & 0 & \ddots & 0\\ 0 & \ldots & 0 & 1_{n} \end{bmatrix}

# CVS - adminstration and usage

Saturday, 26 March 2005 11:46
CVS

To start a repository, a suitable directory on the server machine must be initiated. To initiate, run:
#cvs -d /var/cvs init
This will create a directory CVSROOT under /var/cvs.

By default, CVS adds new files to the repository under the default group of the user performing the addition. But in multi-group repositories, this leads to CVS additions that are not readable by other developers. Fortunately CVS makes it easy to automate associating the new file with the proper group for the project. Edit the file /var/cvs/CVSROOT/loginfo:

Add the following lines to the bottom of the file:
module  (chgrp -Rf groupname $CVSROOT/module) module (chmod -Rf u+rw,g+rw,o=$CVSROOT/module)
Save the file and exit.
This will make sure any additions to the CVS repository will be automatically associated with the project's default group and permissions of user & group read/write, other with no perms.

Often what I do is add the following in one line:
modulename (somecmds;chgrp -Rf groupname $CVSROOT/modulename;chmod -Rf u+rw,g+rw,o-rwx$CVSROOT/modulename;)
This runs somecmds and then changes the group and read permissions for the whole tree.

When you setup a repository, you will want to control access by group (add a group for all the developers and remove writable/readable by others).  When users do checkins and checkouts, do a newgrp to change the effective group.  This will make sure that all new files created will be accessable to the other developers in the cvs group. To find out what groups you have membership to run groups.

Another thing you might want to do is: umask 007  (this will replace any existing umask). This will make all new files with user and group read/write but others have no permission.

To tag the current module use the following:
cvs tag -cR TAGNAME
This tells cvs to tag the module, making sure that working files are unmodified from the repository, and recursively down the tree.

To pull a tagged release use the following:
cvs update -r TAGNAME

When adding binary files under CVS use the cvs admin -kb to set the binary flag.
This issue is transparent unless you checkout to a windows machine.

Keyword List
============
This is a list of the keywords:
$Author$' - The login name of the user who checked in the revision.
$Date$' - The date and time (UTC) the revision was checked in.
$Header$' -  A standard head
$Id$' -  Same as $Header$', except that the RCS filename is without a path.
$Name$' -  Tag name used to check out this file. The keyword is expanded only if one checks out with an explicit tag name.
$Locker$' - The login name of the user who locked the revision.
$Log$' -  The log message supplied during commit, preceded by a header containing the RCS filename, the revision number, the author, and  the date (UTC).
$RCSfile$' -  The name of the RCS file without a path.
$Revision$' -  The revision number assigned to the revision.
`$Source$' -  The full pathname of the RCS file.

The file commitinfo contains a list of pre-commit programs.
The file loginfo file contains a list of post-commit programs.
When you want your pre/post commit programs to reside in the CVSROOT folder, you need to add them in the checkoutlist file.

You can setup email notifications when commits are done using the wonderful program CVSSPAM
A good article on CVS automation: Pragmatic CVS