[Techtalk] Rolling back to revision n-1 from CVS

[Malcolm Tredinnick]

On Wed, Apr 17, 2002 at 12:00:49PM -0700, Megan Golding wrote:
> I'm working with CVS and found a solution to my
> problem but am curious as to what the One Right
> Solution (TM) is. Here's my issue:
> 
> 1. 2 weeks ago, someone checked in version 1.1 of a
> file (its a GIF and is checked in as a binary, if it
> matters).
> 
> 2. 1 week ago, someone else checked in version 1.2 of
> this file. 1.2 was somehow corrupted. 

Was the GIF update committed on a Windows machine and checked out on
Unix box (or vice versa)? If this is the case, then my guess is that the
initial 'cvs add' of the file did not occur with the '-kb' flag. This
flag lets CVS know that the file is binary and it shouldn't do line
ending translations when working on Windows machines.

Of course, that may not be the problem at all, but it's the usual cause
of this sort of complaint.

> I want to "roll back" to 1.1. By roll back, I mean I'd
> like to make version 1.1 the new "current" version. I
> don't care to keep a history of the corrupted version
> around. In other words, I'd be thrilled if version 1.2
> never even happened.
> 
> My solution? 
> 
> 1. cvs-export a version from before 1.2 was checked
> in.
> 
> 2. Copy the uncorrupted (version 1.1) files into my
> working directory.
> 
> 3. cvs-committed. 
> 
> Now, I have version 1.3, which is identical to version
> 1.1. Sure, it works. But, I'm certain there must be a
> better solution.

This isn't a bad way.

The "officially approved" method of rolling something back is to merge
(with -j) the two previous versions and then recommit. So in your case,
the commands would look like:

cvs update -j 1.2 -j 1.1 myImage.gif
cvs commit myImage.gif

Note that the order of the -j commands is important. The first one is
the version to merge from, the second is the version to merge to (so
merge the changes required to get from version 1.2 to 1.1, a reverse
diff, in effect).

Hope this helps,
Malcolm

--