392 Technique 52: Archiving Changes with CVS

Getting Started with CVS

A CVS repository contains all the files that are relevant to a developing project. Each developer (or administrator, or author, or artist) checks out a copy of a project file to make changes to it. The revised file is then committed back to the repository, along with comments (for easy review later). The master copies always live in the repository; each developer checks out a sandbox to play, er, work in.

CVS client software is available for most platforms, so having many developers on a mixed-machine network is easy. You can work in the environment of your choice without causing any conflicts with the overall project.

Checking whether CVS is installed

If you installed the Development Tools package when you set up your Linux system, you probably already have CVS installed. To check, type cvs at the command line and press Enter. If CVS is installed, Linux displays a list of command options.

If CVS isn’t installed on your system, you can find the RPM package on your Linux CD (or DVD), or just search and download an RPM file from the Web. Visit Technique 17 if you need help installing the RPM.

RCS versus CVS

RCS (Revision Control System) is the old versioning software that is included with Linux. Unlike CVS, RCS works only on a local machine, so its usefulness is limited to small projects. CVS is constructed as a wrapper around RCS. The storage mechanisms are the same, but CVS offers more advanced functionality for managing complex projects.

Discovering what to use CVS for

CVS is good for all sorts of projects. It was developed primarily to track changes to software development projects, but it’s great for the following uses as well:

Keeping system configuration changes

Tracking Web site versions

Keeping manuscript backups

Tracking sales lists, inventories, art work, and so on — basically any project that evolves over time

CVS ensures that you won’t lose work. Whatever project you’re working on, you occasionally need to back up, change direction, or just figure out what changed. CVS can do all that in a snap, for anything you can keep in a file.

Creating a CVS Repository

After CVS is installed on your system, you’re just a few quick steps away from having a working CVS repository.

Be sure you have plenty of disk space available on your CVS repository system. Remember that it’s keeping not only the current project, but also the project history. Repositories can be huge, and not having to move them later is a big timesaver.

In this example, you create a CVS repository to track the changes in configuration files. You have to play a few games with permissions because configuration files can be modified only by someone with superuser privileges. Most of the Linux configuration files reside in the /etc directory (or a subdirectory of /etc). You’ll be creating a repository to hold the master copies (and revision histories) of each configuration file. The /etc directory becomes a sandbox; that is, you can check a working copy out of the repository and into the /etc directory tree.

Follow these steps to create a cvs group (only members of this group can interact with the repository) and a CVS repository:

1. Open a command line and give yourself superuser privileges:

$ su

Populating Your Repository with Files

393

2. When prompted, enter the superuser password.

3. Create the cvs group:

# groupadd cvsusers

If you see a message stating that group cvs already exists, just ignore it.

4. Move to the root directory:

#cd /

5.Create a new directory for cvs:

#mkdir cvs

Keeping our repository directly under the root directory is just a matter of preference. It can reside anywhere you like.

6. Change the group ownership of the CVS repository:

#chgrp cvsusers /cvs

7.Set the permissions for the cvs directory:

#chmod g+srwx /cvs

These permissions allow any member of the cvs group to view or modify the files in the repository. The g+s part ensures that all the files that you store within the repository are also owned by the cvs group.

8. Initialize the repository by typing the following command and pressing Enter:

# cvs -d /cvs init

If you look in your new directory, you’ll find a subdirectory called CVSROOT. The CVSROOT directory contains administrative files for use by CVS.

Don’t forget to add the appropriate users to the cvs group (at least add yourself).

A fast way to add a user to your new group is with the command /usr/bin/gpasswd -a username groupname. To use this command, you must hold superuser privileges.

Populating Your Repository with Files

After you’ve created a CVS repository, you need to populate it. For now, just add a few files; you can always add more later.

To add files to your repository, follow these steps:

1. Move to the directory that you’ll be archiving:

#cd /etc

2.Check out the top-level CVS directory:

#cvs -d /cvs checkout .

Don’t forget the . (dot) at the end.

The checkout command creates a sandbox. At this point, the repository holds only CVS bookkeeping information, but later, a sandbox will contain a working copy of each file in the repository.

3. The cvs add command inserts a new file into the repository, so add the hosts file as follows:

#cvs add hosts

4.You can also add subdirectories. This command creates a new subdirectory within the repository:

#cvs add xinetd.d/

5.Now move into the /etc/xinet.d directory:

#cd xinetd.d/

6.Add all the files in /etc/xinet.d:

#cvs add *

7.After the files and directories are added to the repository, move back to /etc:

#cd ..

8.At this point, you’ve scheduled a few files to be added to the repository, but you haven’t committed your changes. To make your changes permanent, use the cvs commit command:

#cvs commit -m “Adding initial files”

394 Technique 52: Archiving Changes with CVS

The -m flag tells CVS that you want to include in the revision history the text that follows. If you don’t include the -m flag (and a comment), CVS prompts you for a comment.

The primary Web site for CVS is www. cvshome.org. This is a handy address to have if you need downloads or more information.

The CVS repository now contains a history file for each file you added. You can’t use these files directly; you have to create a sandbox and grab a working copy. From this point forward, you never change the masters.

If you look into each of the directories that you’ve added files from, you’ll also notice that a CVS directory has been added to each directory. These directories hold the internal bookkeeping information that CVS needs to do its thing.

Checking Files In and Out (Or

Playing in Your Sandbox)

When you want to change a configuration file, check out a copy of the file you need from the CVS repository and place it into your personal sandbox. When you’re finished modifying your local copy, you then commit your changes to the repository. Here’s how to do all that:

1. At the command line, type the following command and then press Enter:

$ mkdir ~/work

This command creates a directory to hold your sandbox.

2. Move into the sandbox directory you just created:

$cd ~/work

3.Check out a work copy of the hosts file:

$cvs -d /cvs checkout hosts

Now, you’ve got a copy of the hosts file (in your sandbox) that you can modify. Fire up your favorite editor and czhange the file as you see fit.

4. Modify your local copy and then commit your changes with the following command:

$cvs commit -m “your comment here” hosts

Use the -m flag to include your comment in your commit statement. It’s not only faster, but also saves you a trip into vi (or vim). vi can be a cold, dark place.

When CVS is finished, it displays a message like this:

Checking in hosts; /cvs/hosts,v <-- hosts

new revision: 1.2; previous revision: 1.1

done

Neat and fast! Your changes are now stored in the CVS repository. CVS keeps enough information to reconstruct any version of the file. Note that you haven’t modified the hosts file in the /etc directory, just the version that’s stored in the repository. You still have to update the /etc sandbox by following these steps:

1. Move into the /etc directory:

$cd /etc

2.Give yourself superuser privileges with the su command (nonprivileged users can’t change the files in /etc):

$su Password:

#

3.Update the hosts file from the CVS repository:

# cvs update hosts U hosts

That’s it. You’ve made a change to an important Linux configuration file, but you’ve saved the original version (in the CVS repository) and a useful comment to tickle your memory later.