Basic CVS command reference...

Prior to using cvs, set up the CVSROOT and EDITOR environment if not set up already.

$ export CVSROOT=/path/to/cvsroot
$ export EDITOR=vi

There are only a handful of CVS commands that you need to know to get everything done to control a project. All the commands share a common general syntax of:

$ cvs [-d cvs_root_path] command [command-options-and-arguments]
  1. init: Create/initialize a project.
    $ cvs -d /path/to/cvs/PROJECT init

    This creates the named directory and makes it into a "CVS root directory".

  2. import: Create/import an archive.
    $ cvs -d /path/to/cvs/PROJECT import -m "CVS archive for module" module module begin

    Imports the entire module tree including all subdirectories and turns it into a CVS archive in the project or default CVS root directory.

  3. checkout: Checkout the project module
    $ cvs -d /path/to/cvs/PROJECT checkout module

    Check out the module to create a new working directory from CVS.

  4. add: Add new files to the project
    $ cvs -d /path/to/cvs/PROJECT add newdoc1 newdoc2 nedoc3...

    The files has been added to CVS, but the archive file doesn't actually exist yet. To create it, we have to "commit" the changes.

  5. commit: Commit changes to save to archive.
    $ cvs -d /path/to/cvs/PROJECT commit

    This saves all changes to the CVS archive auto-incrementing the revision number on all future commits.

  6. update: Update local files
    $ cvs -d /path/to/cvs/PROJECT update -d .

    Updates local files with the files on the CVS archive including all subdirectories.

    When running an update before working on a shared project, always use the additional "-d" flag to be sure to also update any missing directories your co-workers might have added as well as the already existing working copies of the files.

  7. diff: Diff/compare changes between two revisions
    $ cvs -d /path/to/cvs/PROJECT diff -r 1.1 -r 1.2 newdoc1

    This will compare and output the differences between the two revisions of the specified file. You could also pipe this into a patch file to be used later.

  8. tag: Tag current set of changes
    $ cvs -d /path/to/cvs/PROJECT tag version_1_0_0

    Tagging revisions allows for sources to be recovered with the tag name.

    Note that CVS won't permit the "." character in tags, so you cannot use "version.1.0.0" as a tag. version_1_0_0 is permitted.

  9. remove: Remove unwanted files
    $ cvs -d /path/to/cvs/PROJECT remove newdoc1

    Note that file has to be removed first prior to removing it from the cvs archive. Then commit the change to actually remove the file from CVS. This puts the file into the "Attic" folder.

To get more usage info:

cvs --help                      # usage info and general cvs-options
cvs --help-commands             # list & description of commands
cvs --help-options              # general cvs-options
cvs --help command              # command specific usage & command options

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

changing log message after commit

$ cvs admin -m 1.15:"new comment to replace old one" filename

Where 1.15 is the revision number of the file for which the log is to be updated.

Creating and using CVS Branches


$ cd ~/CVS_workspace/daq-common # Beginning in the project you wish to branch
$ cvs up -A # Bring to head of the Trunk
$ cvs tag KSB_DAQ-COMMON_BASE_20041025 # Tag the base point of the new branch
$ cvs tag -r KSB_DAQ-COMMON_BASE_20041025 -b KSB_DAQ-COMMON_BRANCH_20041025 # Create branch based on base point.

$ cvs up -r KSB_DAQ-COMMON_BRANCH_20041025 # Move your working directory onto the branch
$ vi # Edit in branch working directory
$ cvs ci # Commit changes onto branch
$ cvs up -A # Get a Trunk working dir, to do the merge into
$ cvs up -j KSB_DAQ-COMMON_BRANCH_20041025 # Merge in changes from branch
$ cvs -nq up # Look for conflicts
$ ant test # Run unit tests
$ cvs ci -m "Results of merge from KSB_DAQ-COMMON_BRANCH_20041025 branch." # Commit changes into Trunk with meaningfull log message.

difference in tag and rtag

"tag", tags just the files that are present in the working directory and applies the tag to the revision of the file that is checked out.

"rtag", tags the files in the specified module or repository directory and applies the tag to the latest revision on the trunk.

In general, tag is used to tag things you're working on, rtag is used to create a branch off of an existing tagged revision without having to check it out.

create branch from tag

To create a branch from a tag instead of head:

cvs rtag -r <existing-tag/branch> -b <new-branch> <module-name>

Note: "-r" flag must be in front of the "-b" flag.

delete a version of file

To delete a version of a file from CVS:

cvs admin -o1.3 old_file

This would delete just the 1.3 revision number.

delete tagged release

To delete a tagged release that was mistakenly created:

cvs tag -d BAD_REL_1_0

Delete tagged branch

To delete a tagged branch that was mistakenly created:

cvs rtag -d -B <branch name> <module name>

Try with "-n" first to see a dry run.

reverting cvs changes

Check the differences between two different revisions of a file:

cvs diff -r 1.15 -r 1.14 filename

To revert to older version of a file:

cvs update -j 1.15 -j 1.14 filename
cvs commit -m "reverting filename back to 1.14" 

It's safer to revert one version at a time, if you get conflicts when skipping versions... say from 1.15 to 1.13. You would do:

cvs update -j 1.15 -j 1.14 filename
cvs update -j 1.14 -j 1.13 filename
cvs commit -m "reverting filename back to 1.13"

Branch, tag and deployment cycle

Branch project trunk via:

cvs rtag -b RB_1_0 project

Creating Release Branch using rtag applies the tag to the current version in the repository, so make sure repository is up to date and all work is committed prior.

Code can then be checked out to rb-1.0 folder from branch via:

cvs co -r RB_1_0 -d rb-1.0 project

New development goes on in the trunk while the branch is used for bug fixes and getting prepared for actual release.

When ready for deployment tag the release:

cvs tag REL_1_0

Creating RELease using tag applies the tag to the current version in the local workspace.

Similarly, tagged releases, can then be checked out to rel-1.0 folder via:

cvs co -r REL_1_0 -d rel-1.0 project

Changes made for the release can now be merged into mainline trunk code via:

cd project
cvs update
cvs update -j REL_1_0
cvs commit -m "Apply rel-1.0 fixes"

Secure cvs over ssh

  1. Set CVS to use SSH protocol to communicate with server:
          $ export CVS_RSH=ssh
  2. Any CVS operation is now performed securely using the ssh protocol.
          $ cvs -d :ext:USERNAME@HOST:/path/to/cvsroot CVS_COMMAND
  3. Alternately, the root path could also be exported as:
          $ export CVSROOT=":ext:USERAME@HOST:/path/to/cvsroot"

    Then the commands followed would be:

          $ cvs -d $CVSROOT CVS_COMMAND