pacher/tmp

SVN and Cadence

CVS stuffs for VLSI dummies

Doc

Sample work session

Assuming that a repository is already set up:

cd /path/to/working/directory
cvs checkout <module name>

or

cvs co <module name>

This will create a new directory called <module name> and populate it with the source files. A CVS/ directory inside the <module name> directory is used internally by CVS. Normally, you should not modify or remove any of the files in it.

The checkout command can either take a module name as argument or a path name relative to $CVSROOT

cvs co module/path/to/dir

Commit files:

cvs commit <filename>

or

cvs commit -m "Log message" <filename>

If you don't use the -m option CVS starts an editor to allow you to enter a log message, save the temporary file and exit the editor. The environment variable CVSEDITOR determines which editor is started. If CVSEDITOR is not set, then the system environment variable EDITOR will be used. If you want to avoid starting an editor you can specify the log message on the command line using the -m flag instead.

cvs diff <filename>

This command runs diff to compare the version of filename that you checked out with your local working copy.

The repository

The CVS repository stores a complete copy of all the files and directories which are under version control. Normally, you never access any of the files in the repository directly. Instead, you use CVS commands to get your own copy of the files into a working directory, and then work on that copy. When you’ve finished a set of changes, you check (or commit) them back into the repository. The repository then contains the changes which you have made, as well as recording exactly what you changed, when you changed it, and other such information. Note that the repository is not a subdirectory of the working directory, or vice versa. They should be in separate locations.

The repository might be on the local computer, or it might be on a computer across the room or across the world. To distinguish various ways to access a repository, the repository name can start with an access method.

The repository is split in two parts. A CVSROOT subdirectory contains administrative files for CVS. The other directories contain the actual user-defined modules.

There are different options to tell CVS where to find the repository. You can specify the repository absolute path on the command line with the -d option:

cvs -d /path/to/repository checkout <module name>

Or you can set the CVSROOT environment variable to an absolute path to the root of the repository,

setenv CVSROOT /path/to/repository

A repository specified with -d flag will override the CVSROOT environment variable. Once you’ve checked a working copy out from the repository, it will remember where its repository is. (the information is recorded in the CVS/Root file in the working copy).

Users always access the repository through CVS commands,

cvs [options] <cvs command> [command options] <target>

The overall structure of the repository is a directory tree corresponding to the directories in the working directory.

Inside the directories are history files for each file under version control. The name of the history file is the name of the corresponding file with ,v appended to the end,

filename,v

All ,v files are created with read-only UNIX permissions and you should NOT change the permission of those files. The directories inside the repository should be writable by the users that have permission to modify the files in each directory. This normally means that you must create a UNIX group consisting of the users that are expected to edit the files in a project, and set up the repository so that it is that group that owns the directory.

Creating the repository

To create a repository, run the cvs init command. It will set up an empty repository in the CVS root specified in the usual way

cvs -d /path/to/repository init

or

cvs init

if the CVSROOT environment variable has been already set.

The cvs init command is careful to never overwrite any existing files in the repository, so no harm is done if you run cvs init on an already setup repository.

Remote repository

setenv CVSROOT [:method:]hostname:[port]/path/to/repository

e.g.

setenv CVSROOT :gserver:cmssw.cvs.cern.ch:/local/reps/CMSSW

Starting a project with CVS

When you begin using CVS, you will probably already have several projects that can be put under CVS control. In these cases the easiest way is to use the import command over an already existing project directory,

cd /where/you/have/files/you/want/to/install/in/the/repository
cvs import -m "Log message" /where/you/want/them/to/appear/in/the/repository vendor-tag release-tag 

$CVSROOT/where/you/want/them/to/appear/in/the/repository

Unless you supply a log message with the -m flag, CVS starts an editor and prompts for a log message. CVS requires both a vendor-tag and a release-tag string, hence they must be present.

Development area