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


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

Checking out a repository

Managing a repository

Some notes from real world cvs madness

In-reply-to: <>
        (message from Bryan Jeffery Worthen on Fri, 3 Aug 2001 13:41:17 -0600)
Subject: Re: bugfix
CC: martyc, chrism
References:  <>
--text follows thi line--


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

cvs status -v

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

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?