A commit of a new file or an update which changes a file and is followed within the second by a change to that file will result in the file change not being visible to status and commit. This script will create a repository with a file with different contents to the committed file, but which does not show on status or commit as changed. mkdir hgtest cd hgtest hg init echo "1.1.0" > buildno hg add buildno hg commit -m "Add buildno" echo "1.1.1" > buildno Now inspect the repository. $ cd hgtest/ $ cat buildno 1.1.1 $ hg cat buildno 1.1.0 $ hg status $ hg commit nothing changed The same effect can be produced with a change immediately after hg update if the update changed the file content. This somewhat unlikely series of operations comes from a driver I've been doing for Anthill OS, an old continuous integration system.
Changes that do not change the file time or size are not detected. Brute-force detection of such changes would be prohibitively expensive. Possible alternatives: a) full check of all files that have a time that matches the dirstate's time b) full check of all files that match the -current- time c) delay exit until the next second after dirstate updates d) mark all files as one second before current time Solution (a) means some files are perpetually slow to check. When checking out a large repo, the entire repo becomes slow to check. (b) will catch a lot of cases involving automation, but is still racy. (c) will slow operations for many people by 1000%. (d) will occassionally confuse make and friends.
See also issue136
added nosy from issue136
See this thread: http://www.selenic.com/pipermail/mercurial-devel/2007-February/000950.html This patch doesn't actually work because of the following scenario: checkout files a, b immediately modify a and b commit b change to a is now lost So idea (a) below doesn't work.
add nosy from 1326
more accurate title. For the record it is possible to have sub-second resolution for ext3 under linux. With linux > 2.6.11, if the inode size is > 256, nanosecond resolution will work. What is needed for sub-second resolution: - a FS that support it (obviously) - python > 2.5 (I think it's the first version where stat() always returns a float) - on linux, teach osutil.c how to get the nanosecond timestamp and return floats. - change the dirstate format (backward compat can probably be handled with a require flag)
Fixed ages ago.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:41 EDT --- This bug was previously known as _bug_ 618 at http://mercurial.selenic.com/bts/issue618