Home arrow Site Administration arrow Configuring a CVS Server

Configuring a CVS Server

In this third part of a four-part article series on software configuration management, you'll learn how to set up and use a CVS server. We'll also start looking at the patch program. This article is excerpted from chapter three of the book Cross-Platform Development in C++, written by Syd Logan (Addison-Wesley; ISBN: 032124642X).

  1. Configuring a CVS Server
  2. Item 14: Use Patch
By: Addison-Wesley Prentice Hall PTR
Rating: starstarstarstarstar / 0
October 19, 2011

print this article



Setting Up and Using CVS

For those of you who are interested, I describe the steps it takes to set up a CVS server on a Red Hat-based system. The steps I provide here are almost certainly going to be the same when executed on non-Red Hat systems, and may differ in certain ways on other UNIX-based systems, including Mac OS X. The work involved in getting a CVS server up and running is not terribly difficult, and can be done in a relatively short amount of time. You will need root access to the system upon which you are installing the server, and it will help to have a second system with a CVS client so that you can test the result.

That said, if doing system administration makes you nervous, or site policy disallows it, or you do not have root access, check with a local guru or your system administrator for help.

To start the process of getting a CVS server running, you need to download the source for CVS from the Internet, build it, and install it. I retrieved a nonstable version of CVS by downloading the file cvs-1.11.22. tar.gz from http://ftp.gnu.org/non-gnu/cvs/source/stable/1.1.22. You are probably best, however, grabbing the latest stable version you can find.

After you have unpacked the file, cd into the top-level directory (in my case, cvs-1.11.22), and enter the following to build and install the source:

$ ./configure
$ make
$ su
$ make install

Next, while still logged in as root, you need to do some work so that the CVS server daemon executes each time the system is rebooted. The first step is to check to see whether entries like the following are located in /etc/services:

cvspserver 2401/tcp # CVS client/server operations
cvspserver 2401/udp # CVS client/server operations

If these lines donít exist, add them to /etc/services as shown. Next, you need to create a file named cvspserver in /etc/xinetd.d that contains the following:

service cvspserver
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/usr/cvsroot pserver

Make sure the permissions of this file are -rw-r--r--, and that its group and owner are root. This is probably the default, but it doesnít hurt to check.

If you are not yet running the desktop graphical user interface (GUI), fire it up, and from the Red Hat Start menu, select System Settings, Users and Groups to launch the Red Hat User Manager.

In the dialog that is displayed, click the Add Group button and add a group named cvsadmin. Next, click the Add User button, and add a user named cvsuser. You will be asked to provide a password; enter in something you can remember, and when you are done, exit the Red Hat User Manager.

Back in a terminal, and still as root, enter the following:

# cd /usr
# mkdir cvsroot
# chmod 775 cvsroot
# chown cvsuser cvsroot
# chgrp cvsadmin cvsroot

The preceding commands create the root directory for the CVS server. The path /usr/cvsroot corresponds to the value used in the server_args field of the service aggregate that was created earlier in /etc/xinetd.d. The following commands create a locks directory below cvsroot:

# cd cvsroot
# mkdir locks
# chown cvsuser locks
# chgrp cvsadmin locks

Now that the directory exists for the repository, it is time to create the repository. You can do this by executing the cvs init command, as follows:

# cvs -d /usr/cvsroot init

The -d argument specifies the location of the repository.

Now that the repository has been created, change to your home directory (for example, /home/syd), and execute the following command, which will check out the CVSROOT module from the repository that was just created:

# cvs -d /usr/cvsroot checkout CVSROOT
cvs checkout: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg

Next, cd into the CVSROOT directory that was created by the preceding command, and open up the file named config using your favorite editor. Make the contents of this file consistent with the following:

# Set this to "no" if pserver shouldn't check system
# users/passwords.

# Put CVS lock files in this directory rather than
# directly in the repository. #LockDir=/var/lock/cvs

# Set 'TopLevelAdmin' to 'yes' to create a CVS
# directory at the top level of the new working
# directory when using the 'cvs checkout' command.

# Set 'LogHistory' to 'all' or 'TOFEWGCMAR' to log all
# transactions to the history file, or a subset as
# needed (ie 'TMAR' logs all write operations)

# Set 'RereadLogAfterVerify' to 'always' (the default)
# to allow the verifymsg script to change the log
# message. Set it to 'stat' to force CVS to verify
# that the file has changed before reading it. This can
# take up to an extra second per directory being
# committed, so it is not recommended for large
# repositories. Set it to 'never' (the previous CVS
# behavior) to prevent verifymsg scripts from changing
# the log message. #RereadLogAfterVerify=always

After you have made changes to the config file, check it into CVS as follows:

# cvs commit
cvs commit: Examining .
Checking in config;
/usr/cvsroot/CVSROOT/config,v <-- config new revision: 1.2; previous revision: 1.1 done
cvs commit: Rebuilding administrative file database

In the same directory, run the following command to create a password for each user for whom you want to grant access to the repository. Every time you add a new developer to the project, you need to update the passwd file as I am about to describe, and check the changes into the repository:

# htpasswd passwd syd
New password:
Re-type new password:
Adding password for user syd

Now, open the file passwd (which was just created). At the end of the password, append :cvsuser. The result should look something like this:


Next, you must add the password file to the repository, and commit the result:

# cvs -d /usr/cvsroot add passwd
cvs add: scheduling file 'passwd' for addition
cvs add: use 'cvs commit' to add this file permanently
# cvs -d /usr/cvsroot commit
RCS file: /usr/cvsroot//CVSROOT/passwd,v done
Checking in passwd;
/usr/cvsroot//CVSROOT/passwd,v <-- passwd initial revision: 1.1
cvs commit: Rebuilding administrative file database

This should result in two files in /usr/cvsroot/CVSROOT, one named passwd,v and the other named passwd. If there is not a file named passwd in /usr/cvsroot/CVSROOT (this could happen because of a bug in CVS), return to the checked-out version of CVSROOT (for example, the one in your home directory), edit the file named checkoutlist, and add a line to the end of the file that contains the text passwd. Then, doing a cvs commit on the checkoutlist file will cause the passwd file in /usr/cvsroot/CVSROOT to appear.

Now all that is left is to make the modules. Each directory you create under /usr/cvsroot is, logically, a project that is maintained in the repository. You can organize the hierarchy as you see fit. Here, I create a project named client:

# cd /usr/cvsroot
# mkdir client
# chown cvsuser client
# chgrp cvsadmin client

Now that we have created the repository, added a project, and set up some users, we can start the CVS server daemon by kicking xinetd:

# /etc/init.d/xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]

To ensure that the CVS server is running, run the following command:

# netstat -a | grep cvs

If you see output like the following, everything is in order, and you can use the repository:

tcp 0 0 *:cvspserver *:* LISTEN

To test out the new server and repository, find another machine, open up a shell (or a GUI CVS client if you prefer), and then check out the project named client. In the following example, I am using a command-line CVS client, and the server is located on my local network at the IP address

$ cvs -d :pserver:syd@ login
(Logging in to syd@
CVS password:
$ cvs -d :pserver:syd@ co \
cvs server: Updating client

There now should be a directory named client in the current directory. If you cd into the client directory, you should see the following contents:

$ cd client
$ ls

At this point, you can add files and directories to the project with cvs add, and commit them to the repository using cvs commit.

>>> More Site Administration Articles          >>> More By Addison-Wesley Prentice Hall PTR

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: