Rob's Favorite CVS Commands

Creating a cvs directory with the contents of a working directory (wdir)

To place a directory (and all its subdirectories), called "wdir" under CVS control:

   cd wdir

   cvs import -m "Setting up blah blah" rdir yoyo start

e.g,.

   cd ~/dfile/graphicsio

   cvs import -m "making graphicsio" dfile/graphicsio yoyo start

Checking out a repository

Standard checkout
```
 cvs checkout dirname 
```

To place files in a specific directory (different from the one in the repository

 cvs co -d localdirname dirname

e.g.,

   cd
   cvs checkout -d cutil roblibs/cutil
   cvs -d :ext:mom.cvrti.utah.edu:/usr/local/cvsroot co -d cutil roblibs/cutil

places all the files from roblibs/cutil into a local subdirectory cutil.

To checkout from a remote host: Before starting this, make sure you have ssh set as the access mechanism of the remote host will chuck you out. For ksh/bash types, this is

   export CVS_RSH=/usr/local/bin/ssh

   cvs -d :ext:server.host:server-cvs-dir checkout module-name

e.g.,

   cvs -d :ext:mom.cvrti.utah.edu:/u/macleod/cvsroot checkout gfile/lib
   cvs -d :ext:mom.cvrti.utah.edu:/usr/local/cvsroot checkout map3d
   cvs -d :ext:cvsserv.sci.utah.edu:/usr/sci/projects/cvsrepository co SCIRun
   cvs -d :ext:cvsserv.sci.utah.edu:/usr/sci/projects/SpectralElementGroup 
         co -d IEEESBEM0 Latex/Papers/BioElectric/Stochastic/IEEETBME-SBEM07

To get only the files that are in the main directory of the respository, i.e., do not include any of the subdirectories, use the -l (local) flag. e.g.,
```
   cvs -d :ext:csf.cs.utah.edu:/csafe_noexport/cvs/cvsroot checkout -l SCIRun/src
```
checks out all the files in the SCIRun/src directory but nothing below that.
To check from a branch:
```
   cvs -d :ext:csf.cs.utah.edu:/csafe_noexport/cvs/cvsroot co -r v1_4_0 SCIRun
```
Use the -r option to check out from a branch of the repository tree e.g., to get a copy of the 5.2 release of map3d and its direct progency:
```
      cvs checkout -r rel-5-2-bugfix map3d
```
see 5) below for more important details and how to create the branch

Managing a repository

Updating the working copy
```
   cvs update -P
       
```
Updates all the files and prunes any resulting empty directories. The resulting list shows the status of the files as follows:
- U = local file updated from repository
- P = local file updated from repository (but done by sending a patch file instead of the whole thing)
- A = file was added to the repository
- R = file removed from repository
- M - local file was modified
- C = there is a conflict between local and repository versions; look at the file to resolve conflicts
- ? local file that is not part of repository

Committing changes

   cvs commmit -m "message" filename(s)

Add/removing files:

   cvs add [-k_option ] [-m message] file(s)
   cvs commit filename(s)

   rm filename(s)
   cvs remove filename(s)
   cvs commit filename(s)

Add/removing subdirectories:
```
   mkdir dirname
   cvs add dirname
```
There is no need to perform a commit. But you do need to perform a subsequent update to download the new directory by using
```
   cvs update -d
```

Removing directories is funky:

   cd dirname
   rm filename(s)
   cvs remove filename(s)
   cvs commit -m "removal message" filename(s)
   cd ..
   cvs update -P

Removing directories and all their contents:
```
   cvs rm -Rf dirname
   cvs commit -m "blah blah"
   cvs update -P
```
Note the last step, in which we perform an update on the empty directory to get rid of it.

Binary files:

To add a binary file properly

  cvs add -kb -m"message" filename(s)
  cvs ci -m"message" filename(s)

To fix binary files already in the archive

  cvs admin -kb filename(s)
  cvs update -A filename(s)
  cvs commit -m"message" filename(s)

Making a branch:
To create a branch off the main tree of the repository, make a tag that names the new branch, e.g., to make a branch of map3d called rel-5-2-bugfix:
```
     cvs tag -b rel-5-2-bugfix
```
Note: tag name cannot have any special characters (like ".") To check out the latest version along that branch, go to the top of the repository tree and type
```
     cvs checkout -r rel-5-2-bugfix map3d
```
The only way for you to get two working copies is for you to check out two different trees. For example:
```
      cd robs_trunk;
      cvs co map3d;

      cd robs_branch;
      cvs co -r rel-5-2-bugfix map3d;
```
now you have two completey different trees, to use for your purposes. An individual file within your working tree can only be relative to one tag at a time, and you will always have only one of that file.
Be careful not to mix and match. You can checkout a single file relative to any tag, or version, or date within any tree.
To see what tags and hence branches there are:
```
  cvs status -v filename.cc
```
which produces a list of existing tags and also says if there is a Sticky Tag, which means that the file is from one of the branches.
Merging from a branch
To merge the changes from a branch into the main trunk:
1. make sure all branch changes are checked in and committed
2. checkout a fresh copy of the main trunk cvs checkout theprogram
3. update against the branch cvs update -j Tag_name filename.cc
4. commit the merged version back to the main trunk cvs commit
Note the manual section on merging about multiple merging and the need to tag the merge points so that subsequent merges work from the latest copy of the branch.

Some notes from real world cvs madness

    
To: worthen@cs.utah.edu
In-reply-to: <Pine.SGI.4.21.0108031340310.494956-100000@river.cs.utah.edu>
        (message from Bryan Jeffery Worthen on Fri, 3 Aug 2001 13:41:17 -0600)
Subject: Re: bugfix
BCC: macleod@cvrti.utah.edu
CC: martyc, chrism
References:  <Pine.SGI.4.21.0108031340310.494956-100000@river.cs.utah.edu>
--text follows thi line--

Bryan,

You can check this by looking at the sticky tag of any file in your working directory.

cvs status -v filename.cc

and then look at the Sticky Tag: line. If you are on a branch, it will say so and give the name of the branch.

I just tried an update and only got one file

ParseCommandLineOptions.cc

so if you have changes in other files, then I suspect that you have checked them in against the bigfix tag.

Now, it should be easy to merge the branch changes into the main trunk. You just check out a fresh main trunk copy (be careful to commit and get rid of the branch working copy or save it someplace different).

cvs checkout map3d

and then merge the branch in

cvs update -j rel-5-2-bugfix

If there are conflicts--and I don't think this will be the case--you will have to resolve them and then finally run. One can also specify specific files to update by adding them the update command, as in

cvs update -j rel-5-2-bugfix thefile.c

Then when you have reconciled any differences, commit the result back to the trunk.

cvs commit

The problem that the manual talks about is that if we have to merge the branch again later, it will get confused over which version of the branch to merge. There are two solutions, either to merge the two branch versions with two -j commands, but for this, we have to know the version number at the time of the previous merge. Or we mark a tag on the branch whenever we do a merge and then merge against that tag. So then the merge command looks something like

cvs update -j rel-5-2-bugfix-merged -j rel-5-2-bugfix

Confused yet? I am.

I tried the merging myself and it seems to work fine, then I tagged the branch with the command

cvs rtag -r rel-5-2-bugfix rel-5-2-bugfix-merge1 map3d

so we now have a new tag the same branch and this is what we will have to merge from next time.

So, as for how to manage this without spending hours reading the cvs manual, I suggest we try *REALLY HARD* to keep all new development to the main trunk and use the bigfix branch only for small things that we discover are busted with 5.2. It may be easiest to just copy those changes from the branch version manually to the trunk version to avoid having to merge too often; after all, we do not want to be on the branch for very much, right?

So, save your working directory someplace for now, checkout a fresh copy of the trunk and diff the files with what you have to see if you have anything to update from your old working copy. Then develop along the trunk untill we discover a real bug that needs fixing on the branch.

Does that sound reasonable?

Cheers,

Rob