Appeal to respect the development history and time tracking

[Thomas Klausner]

On Tue, Aug 25, 2015 at 05:57:15PM -0400, Gregory Szorc wrote:
> Commit times are initially defined at the time of the original commit. By
> default, if you rewrite history, the commit time is not refreshed. This can
> result in commits from 2014 being pushed today. I can pretty much guarantee
> that any repository with more than 1 author has commit times where the time
> of commit N+1 is not always greater than commit N.
> 
> Also, commit times can be spoofed. See `hg commit --date`.

Assuming that there is only one author, or that people take care to
have a linear history, there is still some sense in commit times as
file system time stamps.

Matt Mackall <mpm at selenic.com> wrote:
> Mercurial is a version control systems that is designed to work in an
> ecosystem of other widely-used development tools like make(1) that
> expect and require the timestamps on changed files to be current to do
> their job correctly.
>
> It's no coincidence that basically all version control systems ever work
> this way: make(1) came first.

CVS checkouts give you the time stamps of the files on the server. In
case new directories are created in your checkout that weren't there
before, also the directory's time stamp is taken from the server.

I actually find that useful, but I guess my use case is perhaps not
very common, or perhaps I'm just used to an accidental "feature".

Cheers,
 Thomas