parsers: make pack_dirstate take now in integer for consistency
On recent OS, 'stat.st_mtime' has a double precision floating point
value to represent nano seconds, but it is not wide enough for actual
file timestamp: nowadays, only 52 - 32 = 20 bit width is available for
decimal places in sec.
Therefore, casting it to 'int' may cause unexpected result. See also
changeset 13272104bb07 fixing issue4836 for detail.
For example, changed file A may be treated as "clean" unexpectedly in
steps below. "rounded now" is the value gotten by rounding via
'int(st.st_mtime)' or so.
---------------------+--------------------+------------------------
"now" | | timestamp of A (time_t)
float rounded time_t| action | FS dirstate
------ ------- ------+--------------------+-------- ---------------
N+.nnn N N | | --- ---
| update file A | N
| dirstate.normal(A) | N
N+.999 N+1 N | |
| dirstate.write() | N (*1)
| : |
| change file A | N
| : |
N+1.00 N+1 N+1 | |
| "hg status" (*2) | N N
------ ------- ------+--------------------+-------- ---------------
Timestamp N of A in dirstate isn't dropped at (*1), because "rounded
now" is N+1 at that time, even if 'st_mtime' in 'time_t' is still N.
Then, file A is unexpectedly treated as "clean" at (*2) in this case.
For consistent handling of 'stat.st_mtime', this patch makes
'pack_dirstate()' take 'now' argument not in floating point but in
integer.
This patch makes 'PyArg_ParseTuple()' in 'pack_dirstate()' use format
'i' (= checking type mismatch or overflow), even though it is ensured
that 'now' is in the range of 32bit signed integer by masking with
'_rangemask' (= 0x7fffffff) on caller side.
It should be cheaper enough than packing itself, and useful to
detect that legacy code invokes 'pack_dirstate()' with 'now' in
floating point value.
$ hg init a
$ cd a
$ touch empty1
$ hg add empty1
$ hg commit -m 'add empty1'
$ touch empty2
$ hg add empty2
$ hg commit -m 'add empty2'
$ hg up -C 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ touch empty3
$ hg add empty3
$ hg commit -m 'add empty3'
created new head
$ hg heads
changeset: 2:a1cb177e0d44
tag: tip
parent: 0:1e1d9c4e5b64
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add empty3
changeset: 1:097d2b0e17f6
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add empty2
$ hg merge 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Before changeset 05257fd28591, we didn't notice the
empty file that came from rev 1:
$ hg status
M empty2
$ hg commit -m merge
$ hg manifest --debug tip
b80de5d138758541c5f05265ad144ab9fa86d1db 644 empty1
b80de5d138758541c5f05265ad144ab9fa86d1db 644 empty2
b80de5d138758541c5f05265ad144ab9fa86d1db 644 empty3
$ cd ..