CVS Hints and Tips

Introduction

Subversion is nothing less than an improvement on CVS. The conversion is not at all painful. There’s even a section in the documentation for CVS users. Downloads etc from http://subversion.tigris.org/. There’s also a package to convert CVS repositories, tags, branches and all to Subversion.

See SubversionTips.

Setup

SSH and RSH

Set the following environment variables:

Linux * export CVS_RSH=ssh or export CVS_RSH=rsh * export CVSROOT=:ext:user@host.com:/var/lib/cvsroot

Windows

  • set CVS_RSH=ssh or set CVS_RSH=rsh
  • set CVSROOT=:ext:user@host.com:/var/lib/cvsroot

PServer

  • export CVSROOT=:pserver:user@host.com:/var/lib/cvsroot

Local

  • export CVSROOT=:local:/var/lib/cvsroot

Operation

Tagging

Each release should be tagged with an appropriate tag. E.g. release_1_1 or perhaps the date of the release or both.

In the root of your working directory, tag a release with:

  • cvs tag release_20021222_version_1_1

Branching

Branching is usually done based on an existing tag. Invariably you are returning to a previous release for which you’re going to make some fixes and re-release. See Tagging

Firstly make a working copy based on the tag. Either checkout a new working copy or convert your existing one.

Checkout a new working copy from the parent directory or your working directories with:

  • cvs checkout -d myproject_release_1_1 -r release_20021222_version_1_1

Convert an existing copy from the root working directory with:

  • cvs update -d -r release_20021222_version_1_1

Now create the actual branch by tagging this release with a branch tag using the -b option:

  • cvs tag -b branch_version_1_1_2

Now we create a new working copy for the branch with:

  • cvs checkout -d myproject_branch -r branch_version_1_1_2 myproject

or convert the existing working copy with:

  • cvs update -r branch_version_1_1_2

Merging

This section describes merging changes back onto the main trunk.

Firstly create a working copy based on the main trunk.

  • cvs checkout myproject or convert an existing working copy with:
  • cvs update -d -A

Do a diff between the main trunk and the branch we’re considering merging changes in from:

  • cvs diff -r branch_version_1_1_2

To merge in the changes, do an update with the join (-j) flag with:

  • cvs update -d -j branch_version_1_1_2

This merges all changes. Alternatively append the filenames to the command to only merge specified files.

Then update the working copy with:

  • cvs update

Deal with any merge conflicts in the normal way, then commit the chages with:

  • cvs commit -m “Merged in changes from branch_version_1_1_2”

Compression

Performance can be improved by telling CVS to use compression for network traffic.

  • cvs -z3 co mymodule
Se e also:
* [T <h <h he CVS book](http://cvsbook.red-bean.com/) ttp://www.squirrelmail.org/wiki/en_US/DevBranching> ttp://www.squirrelmail.org/wiki/en_US/NamingGuidelinesForCVS>

– Frank Dean - 22 Dec 2002

Related Topics: GitSvn, GitTips