How to revert to previous commit in CVS

For legacy reasons, I'm using CVS on a project. Recently I committed some changes which broke our code and I needed to revert them. What's CVS's analog of git revert -r ? Looking at past questions like How to revert big change, CVS commits don't group the files that were changed. Is the only way to revert by using dates? Also, what's the best way to view past changes? CVS log outputs too much info, most of which is unnecessary. I want to see commit messages and changed files.

5 Answers 5

CVS documentation can be found here, but from this site it tells how to revert a single file:

MAKING THE OLD VERSION THE CURRENT VERSION

Save the version of "oldfile" to something else and check out the "current" version.
Note: you must still to do update -A to get the current version, because even though you have > renamed
"oldfile" the tag is still associated with the file "oldfile" and is not removed till > update -A is done.

Then rename the "old" version to the "current" version.
% mv oldfile oldfile.old.ver
% cvs update -A oldfile
% mv oldfile.old.ver oldfile
% cvs commit -m "reverting to version 1.5" oldfile

You can now carry on checking out, editing and commiting the file as normal.

This won't handle many files in a recursive fashion, but hopefully helps.

Hi Dave, thanks for the answer. I ended up using cvs update -j -j to revert, do you know what the difference between these methods are?

@FionaT, they're effectively the same. The method described in my answer just replaces the working copy with the old revision which you then commit as the next revision. Using the 'join' method, CVS does the work for you by comparing the two revisions and creating a patch that captures the differences between the two revisions and then applies it to the local file. Note (I'm sure you know) that you still have to commit the local file after using the 'join method you used.

To back out a revision of a single file, use cvs admin -o .

But Dave M's answer is probably what you want.

I should emphasize (revisiting this answer 8 years after I first wrote it) that this is not equivalent to git revert . The git revert command creates a new commit that reverses the effect of a previous commit. The cvs admin -o command actually removes the commit from history -- and if you remove something other than the most recent commit, it doesn't change the current version.

See the CVS documentation ( info cvs ) if you're on a Unix-like system) for details, or see this link.

Quoting from the manual:

`-oRANGE' Deletes ("outdates") the revisions given by RANGE. Note that this command can be quite dangerous unless you know _exactly_ what you are doing (for example see the warnings below about how the REV1:REV2 syntax is confusing). If you are short on disc this option might help you. But think twice before using it--there is no way short of restoring the latest backup to undo this command! If you delete different revisions than you planned, either due to carelessness or (heaven forbid) a CVS bug, there is no opportunity to correct the error before the revisions are deleted. It probably would be a good idea to experiment on a copy of the repository first. 

It then gives a number of ways to specify a revision, or a range of revisions, to delete.

As it says, this can be quite dangerous; it erases information from the repository, which is usually exactly what any revision control system tries to prevent.

If you don't need to change history like this, just grab a copy of the older version and check it in on top of the bad revision, as Dave M's answer suggests.

And you're right, CVS's emphasis is on individual files; more modern systems tend to emphasize the state of the entire repository.

So far, all of this only lets you process one file at a time.

But you could check out an entire module as of a specified date into a separate directory ( cvs checkout -D date ), then copy the files over your current copy of the module, and check everything in. If you do this, be sure to do a "cvs diff" so you know exactly what changes you're making.

I don't know of a good way to get more concise log information. cvs log with no arguments gives you a log for each file, not in chronological order. cvs log filename gives you a log for a specified file, but doesn't relate it to other files that may have been modified at the same time. Personally, I might consider writing a Perl script that gathers the information printed by cvs log and rearranges it for display, but that's probably more work than you're interested in doing.

There are tools to import CVS repositories into something more modern.