Appeal to respect the development history and time tracking

[Becker, Mischa J]

> -----Original Message-----
> From: Eric Siegerman
> tl;dr: It would be useful -- and not dangerous -- to reset working-file
> timestamps to the relevant commit time on "hg clone". But *only* then.
>
> On 08/26/2015 04:28 AM, Thomas Klausner wrote:
>  > Matt Mackall <mpm at selenic.com> wrote:
>  >> [...] widely-used development tools like make(1) that  >> expect and
> require the timestamps on changed files to be current to do  >> their
> job correctly.
>
> This!
>
>  > CVS checkouts give you the time stamps of the files on the server.
>
> But also this!
>
> They're not contradictory.  What CVS does isn't an accident, but well
> thought out.
>
> Most of the time, CVS does as Mercurial (and everything else) does, i.e.
> nothing.  The mod-date on changed files is what the kernel set it to --
> the moment the working copy was changed.  The reason is as Matt says: if
> I updated to an older version and got that version's timestamps,
> dependent files wouldn't be rebuilt.  This applies to more than just
> make(1), e.g. Python wouldn't recompile modified (but "older") .py
> files, leaving their .pyc's out of date.
>
> On initial checkout, though, CVS sets each working file's mod-time to
> the commit date of that version of the file [1].  The advantage is
> (at-least) two-fold.  First, such a directory listing is obviously more
> meaningful to humans than the entire working tree being stamped with the
> checkout time.
>
> More importantly, though, it preserves the *relative* timestamps of the
> files -- which avoids rebuilding generated files that don't need it. [2]
>
> The Mercurial equivalent of CVS's behaviour would be to reset working-
> file timestamps on "hg clone", but *not* on "hg update", or most other
> operations.  (I doubt that there are any other cases that resetting them
> would be appropriate, but haven't thought it through in
> detail.)
>
>    - Eric

I will be quite happy if this is implemented but I would suggest that "hg update" should reset working file timestamps when it updates from the null revision.  Alternatively both "hg update" and "hg revert" could get a new --timestamp option (-t is already taken) for those of us who don't use a compile program.

Mischa

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.