Mercurial's treatment of directory/file timestamps

Robin Cover robincover at gmail.com
Fri Mar 7 22:25:54 CST 2008


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?

Thanks,

Robin

[1] I scanned the FAQ but found only indirect answer to the question
above.

http://www.selenic.com/mercurial/wiki/index.cgi/FAQ
http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-5b506b483e523b987dfc34361d4a2ccf70757580

[2] The SVN bug (characterized as a feature request) has been discussed at
length since 2001; the developers appear unlikely to ever provide a fix,
as I understand the state of affairs.

-- 
Robin Cover
WWW:  http://xml.coverpages.org
Tel: +1 (972) 296-1783


More information about the Mercurial mailing list