Dave Horner's Website - Yet another perspective on things...
Home Tech Talk Programming CVS - adminstration and usage
112 guests
Rough Hits : 2816884
moon and stars
how did u find my site?

what's a matter

Art does not reproduce the visible; it makes visible.
--Paul Klee
appreciate the information? drop me a line, share, or +1.

CVS - adminstration and usage

Saturday, 26 March 2005 11:46

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
Multi-Group CVS Administration HOWTO

< Prev  Next >
Last Updated on Friday, 04 July 2014 15:43