Re: FW: CVS problem

[Eric Siegerman]

On Wed, May 09, 2001 at 05:42:14PM +1200, Chris Cameron wrote:
> % cvs co foo/bar.cc
> % cd foo
> % ls -l
> % rm bar.cc
> % cvs update bar.cc
> % ls -l
> % rm bar.cc
> % vi CVS/Entries              (remove the line for bar.cc)
> % cvs update bar.cc
> % ls -l

> Our developer expected the
> timestamp to revert to the original co timestamp.

Do you mean, after the first "update"?

> The checkout gets the correct timestamnp on the file.

Which timestamp is that?  ("Correct" is imprecise; your idea of
the expected value may differ from mine.)

What CVS is supposed to do on a checkout is give each file the
timestamp of the revision from which it's being created.  (Don't
forget that in the repo, and in the output from "cvs log", the
timestamps are in GMT.)

> The first update gives bar.cc a timestamp which corresponds to the
> time you issued the update command.

Yes.  This is to make sure a subsequent "make" recompiles it.  If
foo.cc came back with the revision's timestamp, that might be
older than an existing, but now incorrect, bar.o file; make would
decide that bar.o was up to date, even though it isn't.  This
behaviour is sometimes annoying, I agree, but the benefit is well
worth the cost :-)

> The second update give bar.cc the timestamp of the original
> checkin time of bar.cc

This I find surprising.  I verified it, though, with cvs 1.11.
I'd have hoped it would behave like the first update, stamping
the file with the current time.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)