Appeal to respect the development history and time tracking

[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


[1] In CVS, per-file timestamps are trivial because of its primitive 
data model (commits aren't first-class entities; a CVS repo is just a 
collection of independently version-controlled files).  In a more modern 
VCS, determining per-file timestamps might take work (though probably 
less work -- and more accuracy -- for the VCS itself to do it than to 
try to reverse-engineer them after the fact).  But either way, per-file 
is the desired behaviour.

[2] It *is* occasionally appropriate to version-control generated files 
-- in the Autoconf/Automake world, for example.  It's especially 
annoying to have a VCS mark the generated "configure" file as older than 
its "configure.ac" source, and all of the project's Automake-generated 
Makefiles as likewise out of date, when you don't have the whole 
Autotools toolchain installed -- or when you have the wrong versions, 
which don't work with the package you're trying to build.