tests/test-double-merge.t

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 repo
  $ cd repo

  $ echo line 1 > foo
  $ hg ci -qAm 'add foo'

copy foo to bar and change both files
  $ hg cp foo bar
  $ echo line 2-1 >> foo
  $ echo line 2-2 >> bar
  $ hg ci -m 'cp foo bar; change both'

in another branch, change foo in a way that doesn't conflict with
the other changes
  $ hg up -qC 0
  $ echo line 0 > foo
  $ hg cat foo >> foo
  $ hg ci -m 'change foo'
  created new head

we get conflicts that shouldn't be there
  $ hg merge -P
  changeset:   1:484bf6903104
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     cp foo bar; change both
  
  $ hg merge --debug
    searching for copies back to rev 1
    unmatched files in other:
     bar
    all copies found (* = to merge, ! = divergent, % = renamed and deleted):
     src: 'foo' -> dst: 'bar' *
    checking for directory renames
  resolving manifests
   branchmerge: True, force: False, partial: False
   ancestor: e6dc8efe11cc, local: 6a0df1dad128+, remote: 484bf6903104
   preserving foo for resolve of bar
   preserving foo for resolve of foo
   bar: remote copied from foo -> m (premerge)
  picked tool ':merge' for bar (binary False symlink False)
  merging foo and bar to bar
  my bar@6a0df1dad128+ other bar@484bf6903104 ancestor foo@e6dc8efe11cc
   premerge successful
   foo: versions differ -> m (premerge)
  picked tool ':merge' for foo (binary False symlink False)
  merging foo
  my foo@6a0df1dad128+ other foo@484bf6903104 ancestor foo@e6dc8efe11cc
   premerge successful
  0 files updated, 2 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)

contents of foo
  $ cat foo
  line 0
  line 1
  line 2-1

contents of bar
  $ cat bar
  line 0
  line 1
  line 2-2

  $ cd ..