Re: checkout prior version of file

[Eric Siegerman]

On Sat, Sep 27, 2003 at 06:13:32AM -0700, Terrence Brannon wrote:
> I want to 
> do the following:
> 
> 1) get version 1.3 of this file into my current working directory
> 2) edit this file
> 3) make the edits become version 1.5 and continue working.

[I guess you meant 1.2 here, or 1.3 later on.  I'll assume the
former (mostly because it makes a better example that way :-)
Adapt my instructions as necessary.]

In other words, you want to back out the 1.3 and 1.4 changes,
right?

Before we get to the mechanics, the first thing I'd recommend is
an additional commit:
  1) get version 1.2 [I assume you meant] of this file into my
     current working directory
 1a) make this (i.e. a copy of the unmodified 1.2) become version
     1.5
  2) edit this file
  3) make the edits become version 1.6[!] and continue working.

(1a) commits the unmodified version 1.2 as the new 1.5.  That
makes it easier for later readers to follow what happened.  The
risk, of course, is that you'll break the build during the period
between (1a) and (3).  If that's unacceptable, you can always
shuffle files around to effectively swap steps (1a) and (2),
thereby reducing the breakage window to as long as it takes to:
    $ cvs ci file1
    $ mv file1-edited file1
    $ cvs ci file1
    type log message

> I saw a means to do step 1) as follows:
> 
> $ co -p1.2 `cat CVS/Repository`/file1,v > file1
> $ cvs diff file1
> $ cvs commit -m"reverted to version 1.2 which worked" file1
> but:
>   (1) this looks sort of like I am peeking under the hood. it seems that I 
> should be able
>       to make a CVS call to do this

You're right.  You can easily do the same thing without
"peeking"; replace the first step with:
    $ cvs update -p -r1.2 file1 >file1

That's still cheating a bit, though.  The much better way to do
it is:
    $ cvs update -j1.4 -j1.2 file1

Note that the higher revision number is given *first*.  This
method will work even if you've got uncommitted changes in your
working copy of the file; the other two methods (which are really
the same method, just using different commands) would clobber
your changes.  (Of course, doing this with uncommitted changes
would go against my recommendation to break the process into
several commits.)

>   (2) I assume that the commit will properly bump the version number to +0.1 
> past the latest version
>       in this example?

Of course :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
        - Michael Collins, Apollo 11 Command Module Pilot