CVS doesn't provide a rollback command.  However, you can use the -j to
roll back a file to a previous version. First, determine the version 
that you want to roll back _to_. Let's call it 1.N (where N is some number).
To roll back a file named "foo":

$ cvs update -j HEAD -j 1.N foo

Verify that all is well, and then commit. e.g.

$ cvs update -j 1.9 -j 1.8 foo
$ cvs commit -m "rolled back to 1.8 version" foo

The file-by-file approach is tedious. You have to go thru each file to
see what the file version should be.  However, you can rollback by using
'cvs update -D $some_date', but this leaves all of the files sticky.

How to make 'em current? Well, here's a way -- note, it's dangerous, and
rolling back code can upset other developers, so be cautious:

(bourne shell version)
$ for i in `find . -type f -print | grep -v CVS` ; do mv $i _$i ; cvs up -A $i ; mv _$i $i ; cvs add $i ; cvs commit -m "Rollback" $i ; done

There's probably a better way, and I suspect it's this:

   cvs checkout -D $some_date $modulename
   cd $modulename
   cvs tag REVERT_TAG
   cvs update -A
   cvs update -j HEAD -j REVERT_TAG
   cvs commit -m "Rolled back $modulename to $some_date"

You can probably delete the tag 'REVERT_TAG' when you're done, too, as you
won't need it anymore (unless you want to record the exact snapshot you
reverted to -- in which case, pick a better name).

Branch Rollbacks:

    cvs admin -o:the_branch # remove the branch revisions
    cvs tag -d the_branch # remove the branch tag

It is very dangerous to remove revisions like that because if you mess up, 
you'll have to restore from backups.  Try these commands on a test repository 
before you work them into your process.     (From http://tinyurl.com/2pgol)


Repository moves:

Every so often you have to deal with a repository being moved on you. This
isn't always a problem, except that sometimes you've done something silly
like, oh, checking out the module with an IP address in the CVSROOT instead
of a domain name.

But, since CVS keeps the CVSROOT around in the local copy, this is relatively
easy to fix.

Assuming that the local working copy is in the directory named "module",
that the old ip address is "old-ip-address", and the new domain name is
"new-domain-name", you can do this:

(bourne shell version)
$ cd module
$ for i in `find . -type f -name 'Root' -print | grep CVS` ; do cat $i | sed -e 's/old-ip-address/new-domain-name/' > $i ; done
$

(csh shell version)
% cd module
% foreach i ( `find . -type f -name 'Root' -print | grep CVS` )
   cat $i | sed -e 's/old-ip-address/new-domain-name/' > $i
  end
%


Creating a branch

So, you've made some changes to the source, and they're more extensive
than you estimated, and pulling on that thread just keeps on going. You'd
like to put your code into CVS for safekeeping, but you don't want to
commit it to the trunk (stable branch, etc.) -- you'd rather have it in a
branch of its own so you can go home now and get back to it later, without
having to buy your team lunch for "breaking the tree".

Let's say you're going to name your branch BRANCH_NAME. Then you can
type:

% cvs tag -b BRANCH_NAME ; cvs up -r BRANCH_NAME ; cvs commit -m "Branching."

(Thats one one line of three commands. You can replace the ; with && if you'd
like, or type each command individually.)