[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: CVS problem

From: Eric Siegerman
Subject: Re: FW: CVS problem
Date: Thu, 10 May 2001 21:41:59 -0400
User-agent: Mutt/1.2.5i

On Wed, May 09, 2001 at 05:42:14PM +1200, Chris Cameron wrote:
> % cvs co foo/
> % cd foo
> % ls -l
> % rm
> % cvs update
> % ls -l
> % rm
> % vi CVS/Entries              (remove the line for
> % cvs update
> % 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 a timestamp which corresponds to the
> time you issued the update command.

Yes.  This is to make sure a subsequent "make" recompiles it.  If 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 the timestamp of the original
> checkin time of

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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]