GNU Info

(cvsbook.info)Examining And Reverting Changes

---

Next: The Slow Method Of Reverting Prev: Finding Out Who Did What (Browsing Log Messages) Up: A Day With CVS

---

Enter node , (file) or (file)node

Examining And Reverting Changes
-------------------------------

Suppose that, in the course of browsing the logs, qsmith sees that
jrandom made the most recent change to hello.c:

     revision 1.4
     date: 1999/04/20 04:14:37;  author: jrandom;  state: Exp;  lines: +1 -1
     adjusted middle line

and wonders what jrandom did? In formal terms, the question that qsmith
is asking is, "What's the difference between my revision (1.3) of
hello.c, and jrandom's revision right after it (1.4)?" The way to find
out is with the diff command, but this time by comparing two past
revisions using the -r command option to specify both of them:

     paste$ cvs diff -c -r 1.3 -r 1.4 hello.c
     Index: hello.c
     ===========================================================
     RCS file: /usr/local/cvs/myproj/hello.c,v
     retrieving revision 1.3
     retrieving revision 1.4
     diff -c -r1.3 -r1.4
     *** hello.c     1999/04/20 02:30:05     1.3
     --- hello.c     1999/04/20 04:14:37     1.4
     ***************
     *** 4,9 ****
       main ()
       {
         printf ("Hello, world!\n");
     !   printf ("between hello and goodbye\n");
         printf ("Goodbye, world!\n");
       }
     --- 4,9 --
       main ()
       {
         printf ("Hello, world!\n");
     !   printf ("BETWEEN HELLO AND GOODBYE.\n");
         printf ("Goodbye, world!\n");
       }
     paste$

The change is pretty clear, when viewed this way.  Because the revision
numbers are given in chronological order (usually a good idea), the diff
shows them in order.  If only one revision number is given, CVS uses the
revision of the current working copy for the other.

When qsmith sees this change, he instantly decides he likes his way
better and resolves to "undo"-that is, to step back by one revision.

However, this doesn't mean that he wants to lose his revision 1.4.
Although, in an absolute technical sense, it's probably possible to
achieve that effect in CVS, there's almost never any reason to do so.
It's much preferable to keep revision 1.4 in the history and make a new
revision 1.5 that looks exactly like 1.3.  That way the undo event
itself is part of the file's history.

The only question is, how can you retrieve the contents of revision 1.3
and put them into 1.5?

In this particular case, because the change is a very simple one, qsmith
can probably just edit the file by hand to mirror revision 1.3 and then
commit.  However, if the changes are more complex (as they usually are
in a real-life project), trying to re-create the old revision manually
will be hopelessly error-prone.  Therefore, we'll have qsmith use CVS to
retrieve and recommit the older revision's contents.

There are two equally good ways to do this: the slow, plodding way and
the fast, fancy way.  We'll examine the slow, plodding way first.