How to revert to previous commit in CVS

Question

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 <old_revision>?

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.

Wrap

Answer 1

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.

Forge

Hi Dave, thanks for the answer. I ended up using cvs update -j <current rev> -j <old rev> <filename> to revert, do you know what the difference between these methods are? – Wrap

@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. – Forge

Answer 2

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.

Philippa

Oh, I didn't know about deleting a subset of revisions. It does sound dangerous especially since I don't own the repository. Could be interesting to play with, though! Do you know if people use it much in practice? – Wrap

@PoC That's surprising. Certainly cvs admin -o... is dangerous, but it's a feature of CVS. If you need it, you can always build CVS from source. (I see a downvote about the same time as your comment, which seems odd. I can always update the answer with that information.) – Philippa

@PoC I just tried cvs admin -o... on Debian 10 buster (CVS 1.12.13-MirDebian-27) and it worked. Can you provide evidence that it's not a valid option? – Philippa

No, I can't. I didn't find -o in the manual page, but I maybe rushed too much. I'll delete my comments tomorrow to not create confusion. Downvote is because I like Vijay Shetty's method best. The answer is short and concise and it actually helped me while other answers in here were cumbersome with renaming and deleting and whatnot. – Gwinn

Answer 3

Here are commands.

1) false commit happen

2) check its latest version.

cvs log file.txt

lets say 1.25 is the latest version due to false commit so we want to revert back to its older version 1.24.

3) So lets go ahead as below way.

cvs update -r 1.24 file.txt // checkout older version
cp file.txt old.txt // create backup
cvs update -A file.txt // again move to latest one
cp old.txt file.txt // replace old to at latest one.
cvs status file.txt // It will shows as locally modified.
cvs commit -m "Reverting false commit"  file.txt
cvs log file.txt // new 1.26 will be created.

4) Just to ensure lets diff that 1.26 and 1.24 are the same one.

cvs diff -r 1.26 -r 1.24 file.txt 

If all above steps are correct then diff will show no difference.

Asco

Answer 4

With two -j options, CVS will merge in the changes between the two respective revisions.

Example:

If the file @file{foo.c} is based on revision 1.6 and you want to remove the changes made between 1.3 and 1.5, you might do:

$ cvs update -j1.5 -j1.3 foo.c   # note the order...

Chicago

This is the simplest, most direct solution. No moving, copying, or renaming files - let the VCS do what it's built to do. No multiple commands - just the single, relevant one. The syntax with both revision numbers mirrors diff's syntax, which works out nicely because with that you can see exactly what your "revert" will do. Reverse the revision numbers and you put your changes back in; useful for when someone asks you to take something out and then, last minute, has you put it in after all. – Hobbema

Answer 5

As well as reverting by date you could revert by tag, if the set of files you want to go back to is tagged.

I had what I think is a similar situation and I did the following which affected the whole folder rather than file-by-file:

• cvs export the 'old version' by tag (or you could do it by date) into a new folder
• ensure the 'current version' is checked out, updated, and live
• copy the files from the old version into the folder with the current version
• commit the result with a suitable comment

This approach will need modification if any files have been added/removed between the old version and the current version.

The CVS history will show the reversion.

Constringe