CVS

CVS is a basically an improved multiuser RCS package. I am providign a list of common flags. For more complete information look at the man pages on cvs.

Starting a new repository

Set CVSROOT
If you don't you must pass the directory to specify the repository location on all cvs commands ( I explain this more in the section on CVSROOT ). For my own I just add the export command to my ".bash_profile" :

export CVSROOT=${HOME}/cvsroot/

You then want read that in to update the environment, like this :

source ~/.bash_profile

Initialize the repository
You need to create/setup the repository, like this :

cvs init

These steps only need to be done once for each repository, not project. You may endup having multiple repositories, so you may need to change your CVSROOT to switch repositories.

Starting a new project ( import )

Use import to start a new project

cvs import project_name vendor start

vendor and start are tags, don't get to worried about them just yet, but you must provide two tags ( a vendor tag and a start tag, I just call them vendor and start ). You will use the project_name for several other cvs commands ( the project name must be unique within the repository ).

You should get rid of the directory your code was in, since it is all in the repository and should now be checked out.

Checking code out ( checkout, co, get )

To get code from the repository, do this:

cvs get project_name

This will get all of the files and create the directories for you. It will put them in a directory with the same name as project_name. This copy of the code is usually referred to as a sandbox ( since you are going to play with it ).

Checking code in ( ci, com, commit )

If you are in the sandbox for the project, you can omit the project_name, otherwise you need to list it.

cvs com

This will update any changes to the repository. If you added new files, it will not do this however, there is a seperate command for that. This is so you don't accidentally check in executables or output files.

Adding files to a project ( ad, add, new )

If you need to add files to an existing project, since checkin does NOT do this for you.

cvs add filename

You can use wildcards instead of the filename, and it is smart enough to realize which files already are in the project.

NOTE: adding a file does not do a commit/check in, so do that after adding the file(s).

Releasing code ( release, re, rel )

When you are done with a project, you will not need a repository copy, and a working copy. To eliminate the working copy we use the release command.

Change directory to one above the working copy and type :

cvs rel -d project_name

The "-d" here actually removes the working copy, otherwise you can use rm to do this.

Tagging a project ( ta, tag, release )

This assigns a named tag to the committed source code.

cvs tag tag_name

You can use any name for a tag. This is required for the export and branch commands.

If you want to see all of the tags on a project use

cvs status -v

I usually pipe that into less. It will show all versions and tags on every file in the project.

Distibuting finished/stable code ( ex, exp, export )

You must have tagged the project. This so that all exports are repeatable. Change directory into your checked out project, and do this:

cvs exp -r tag_name -d dest_directory .

If you are in your sandbox, this will create a copy of the code in dest_directory/project_name/

I highly recommend that the dest_directory be outside of the sandbox.

This is usefull to do before using shar or tar to archive, turn in, or distrubute the code.

additional notes

Learn more at cvshome.org

CVSROOT

For all of the cvs tools you must provide a repository location. This can be done explicitly with "-d" flag, or it will use the environment variable CVSROOT. Note the -d flag is for cvs, not the cvs command, for example doing an init this way is :

cvs -d ~/cvsroot init

logfile symbols

All of the expanded symbols in RCS work in CVS. Look at the rcs symbols.

Working in groups

One person needs to create a cvs repository, set the group on the directory, and make it accessable to the group. In this example my group is named testgroup and the users are jclark, mf000, and aa000. I put the repository in my home directory.

Everyone in the group will want to set these.

export CVSROOT=~jclark/cvsgroup
newgrp testgroup
umask 006

Create the repository, and get the permissions right. Set the group and the 2 in the chmod is the sticky bit, it says all new files in the directory belong to the same group as the directory, even if I forget the newgrp command to change it.

cvs init
chgrp -R testgroup ~jclark/cvsgroup
chmod 2770 ~jclark/cvsgroup

When you do your first checkout you will need to perform the two permission steps on that as well, or the files will only belong to the creator, not the group.

Resolving conflicts ( up, upd, update )

If you go to do a checkin and there is a conflict, it will abort the checkin, and tell you to update. From inside the sandbox run this :

cvs upd

It will update every file to the current version, and where there are conflicts, it will tell you. Now you need to edit the file and resolve the conflicts. They are in diff mode, showing yours and thiers, and you have to be blind not to find them. Once you have resolved the conflicts the code can be checked in ( unless someone beat you to it again ).