Mercurial's treatment of directory/file timestamps

[Matt Mackall]

On Fri, 2008-03-07 at 22:25 -0600, Robin Cover wrote:
> This question is from a potential user of Mercurial [1], hopeful
> that an answer will help with decision-making about choice of
> a version control system (VCS).
> 
> Application: I want to use a VCS for management of documents published
> on the Web.  While most documents are static (e.g., PDF, ZIP,
> XML, HTML, TEXT, TGZ, JPG) and don't require version control per se,
> some are frequently edited, and thus would benefit from some
> features of a VCS.
> 
> Subversion (SVN) was recommended as a first choice, but I cannot
> use it on account of one fatal design flaw: upon SVN import (commit),
> directory and file time[stamp] in the SVN repository is set to
> now/current, destroying UNIX mtime values [2].  I have thousands of files
> with timestamps extending over more than a decade.  Some
> web applications (e.g., search engines) and some local applications
> depend critically upon file mtime.  I cannot use a VCS that destroys
> file timestamps/mtime at commit time.  Further, I need to be able
> to checkout/export/clone files from the repo to create new data sets
> where all the historic mtime values are preserved in the copies
> (e.g., just as ZIP or tar would do).
> 
> Initial investigation suggests that Mercurial does not suffer from
> the above-mentioned design flaw: I could have a local repository on
> one UNIX machine, with SSH routines to push/pull files to a second
> Mercurial repository on a remote machine where the Web server lives;
> file timestamps on the remote machine would be identical to those
> on the local machine/repository, allowing me to protect file
> 'mtime' values from 1996 onward. Mercurial itself would never destroy
> or muck with file 'mtime' values.
> 
> Correct?

Mercurial will not touch timestamps at checkin. But it will also not
store timestamps in the repository (except for the single timestamp on
the commit message itself), so it can't restore timestamps either.

There are ways to manually add timestamp handling with hooks though.