In organizations or departments containing multiple development groups, it is advantageous to administer each group’s projects into using one central server. This document describes how to create a central CVS repository for n number of development teams. This repository will contain m number of developers with a mix of single and multi-project permissions.

Other resources:
Open Source Development with CVS
By: Karl Fogel and Moshe Bar
(full CVS administration text available online)
[http://cvsbook.red-bean.com/]

Setting Up The Repository

It is assumed that the CVS command set is already installed on the target server. (If it is not, consult “Repository Administration -> Getting And Installing CVS” from the text above) This document was created referencing the following version of CVS:

# cvs --version  Concurrent Versions System (CVS) 1.12.2 (client/server)  Copyright (c) 1989-2003 Brian Berliner, david d `zoo' zuhn,                         Jeff Polk, and other authors 

To start a repository, a suitable directory on the server machine must be initiated. This author recommends /var/cvs as a common convention. To initiate, run:

# cvs -d /var/cvs init

To check the initialization, run:

# ls /var/cvs/CVSROOT checkoutlist     config,v        history     notify     taginfo,v checkoutlist,v   cvswrappers     loginfo     notify,v   verifymsg commitinfo       cvswrappers,v   loginfo,v   rcsinfo    verifymsg,v commitinfo,v     editinfo        modules     rcsinfo,v config           editinfo,v      modules,v   taginfo 

Setting Up Multiple Developers (and Groups)

CVS uses the permissions management of the supporting operating system. The tools for managing users and groups vary from distribution to distribution. However the following example should match most any Linux install.

Assume there are three developers, Tom and Mark and Sara, working on two projects, Foo and Bar. The developer’s access needs to be:

Tom needs access to project Foo.
Mark needs access to project Bar.
Sara needs access to both projects Foo and Bar.
It is necessary to set up a login for each user and a group for each project. After that, users need to be assigned to the groups that are associated with the projects they have access to.

# useradd tom [...] # useradd mark [...] # useradd sara [...] 

Add the development groups for each project:

# groupadd cvs-foo # groupadd cvs-bar 

In some setups, users default to the group users. In others, unique groups are created for each user. Either way, add the users to the appropriate development groups just created. (remember that Sara needs to access both projects Foo and Bar) Group information is stored in a file /etc/group. Edit it with the following command: (if you prefer, substitute nano with your favorite text editor - pico, vi, etc.)

# nano -w /etc/group

Look for the group lines for the development groups added above. (they should be at the bottom of the file)

cvs-foo:*:1000: cvs-bar:*:1001: 

Add the developers:

cvs-foo:*:1000:tom,sara cvs-bar:*:1001:mark,sara 

Save the file and exit the editor. You can check the developer’s group associations with the following commands:

# groups tom tom : users cvs-foo  # groups mark tom : users cvs-bar  # groups sara tom : users cvs-foo cvs-bar 

Adding (or Migrating) CVS Projects to the Repository

Importing a standalone project into CVS (using the cvs import command or a GUI front-end like WinCVS), while generally simple, is outside the scope of this HOWTO. To use cvs import, consult the CVS text referenced above, specifically the chapter:

An Overview of CVS -> Basic Concepts -> A Day With CVS -> Starting A New Project
[http://cvsbook.red-bean.com/cvsbook.html#Starting_A_New_Project]

To use WinCVS (available at http://wincvs.org/), consult:

WinCVS — Daily Use Guide -> Chapter III: Starting a New Module
[http://www.thathost.com/wincvs-howto/#startingnew]

Migrating an existing repository from a different CVS server is not much more than copying the repository files directly. To simplify matters, it is suggested that you keep developer usernames on the new server identical to the usernames on the old server. To create a copy of the old repository, run the following command:

# tar -czvvf foo.tar.gz /var/cvs/foo [...] 

Copy that file to the new repository server:

# scp foo.tar.gz mark@newserver.kered.org: mark@newserver.kered.org's password: *********** foo.tar.gz                      100%  25MB  724KB/s 00:35 

Log off the old server and log into the new server. Then, extract the file into the new CVS repository:

# cd /var/cvs # tar -xzvf ~/foo.tar.gz [...] 

Recreate the development groups as shown in “Setting Up Multiple Developers (and Groups)” above. Then run the cvs-clean_permissions file (from Appendix A) to reset the permissions on the new repository. You can test the repository by running the cvs checkout command from any of the developer’s computers. (or anywhere access is available to the developer’s login)

Automating Group Permissions for Files Added to the CVS Repository

By default, CVS adds new files to the repository under the default group of the user performing the addition (usually the group users). 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:

# nano -w /var/cvs/CVSROOT/loginfo

Add the following lines to the bottom of the file:

foo (chgrp -Rf cvs-foo /var/cvs/foo) bar (chgrp -Rf cvs-bar /var/cvs/bar) 

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.

Appendix A - Resetting Bad Repository Permissions

Since CVS uses the permissions management of the parent OS, improper management can result in bad permissions in your CVS repository. This script automates the task of resetting CVS repository permissions when some other program (or admin) has ravaged your repository. To run, create the following file called cvs-clean_permissions.

IFS=:  if [ $# -ne 2 ] then   echo "+--------------------------------------------------+"   echo "| This script will clean up the group associations |"   echo "| and permissions in your CVS repository.          |"   echo "+--------------------------------------------------+"   echo "Usage:    ./cvs-clean_permissions  "   echo "EXAMPLE:  ./cvs-clean_permissions /var/cvs/foo cvs-foo"   echo ""   exit $E_BADARGS fi  # usage: cvs-clean_permissions    echo “changing directory $1 to group $2…” chgrp -R “$2″ “$1″ echo “setting permissions to u=rX,g=rX,o= for $1…” chmod -R u=rX,g=rX,o= $1 echo “adding permissions u+w,g+w to all directories in $1…” for file in $( find $1 -type d -printf “%p$IFS”) do   chmod u+w,g+w “$file” done echo “done!” 

To use, first make the code executable:

chmod +x cvs-clean_permissions

Then run the command, giving it first the location of the project you wish to reset permissions on (/var/cvs/foo), and then the group you want to associate the project with (cvs-foo):

./cvs-clean_permissions /var/cvs/foo cvs-foo changing directory /var/cvs/foo to group cvs-foo... setting permissions to u=rX,g=rX,o= for /var/cvs/foo... adding permissions u+w,g+w to all directories in /var/cvs/foo... done! 

This entry was posted on Tuesday, January 20th, 2004 at 4:41 pm and is filed under programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.