File not marked as 'M' when contents differ from repo

[Jim Hague]

A relative newcomer to Mercurial, I am both (a) deeply impressed, and (b) keen
to try it out on one work project where we need a more distributed model than
possible with the current Subversion setup.

So by way of familiarising myself with Mercurial, I've been writing a
Mercurial backend for Anthill OS, which we're currently using on the
project. But I've hit a problem - somehow I am managing to generate a
repository where a file contents are changed from the repository, but
the file does not register as changed.

jim at malfoy:/tmp/test$ hg cat buildno
1.1.0
jim at malfoy:/tmp/test$ cat buildno
1.1.1
jim at malfoy:/tmp/test$ hg status
? goodbye
? goodbye.o
? hello
? hello.o

A tarball of the registry is at 
http://www.bear-cave.org.uk/linux/hg/test.tar.gz.

I guess it's timestamp-related, as 'touch buildno' restores sanity.

I've tried to reproduce it by hand, but so far without success. The
sequence of operations Anthill is carrying out for a build is as follows:

# For a clean build, first Anthill removes all files in the repository 
except .hg*.

# Get tip revno as the build revno.
hg heads

# Get build source
hg update --clean <build revno>

# Anthill now increments the version number in file 'buildno'.
# Try (unsuccessfully) to check it back in.
hg commit --user "Anthill  <anthill at work.co.uk> \
   -m "Anthill: Increment build number" buildno
nothing changed

# Build.

# Tag the build on success.
hg tag --user "Anthill <anthill at work.co.uk>" -r <build revno> \
   -m "Anthill: Tag build" build-1.1.2

So, it's all coming unstuck when committing the incremented build number.
The change isn't noticed, so on the next time round 'buildno' is wiped and
the old number is in the copy from 'hg update'. So my build number remains
static :-( Copying the repository, I can see the lack of visibility of the
change in both the Mercurial versions in Debian testing (0.9.3-2) and unstable 
(0.9.4-1).

Am I doing something obviously evil?
-- 
Jim Hague - jim.hague at acm.org        Never trust a computer you can't lift.