Ndtyjky

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.

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.

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

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.

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.

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...

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.