tests/test-issue1175.t
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
Wed, 14 Oct 2015 02:40:04 +0900
changeset 26630 3111b45a2bbf
parent 26614 ef1eb6df7071
child 27625 cdb9493a7e2f
permissions -rw-r--r--
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.

https://bz.mercurial-scm.org/1175

  $ hg init
  $ touch a
  $ hg ci -Am0
  adding a

  $ hg mv a a1
  $ hg ci -m1

  $ hg co 0
  1 files updated, 0 files merged, 1 files removed, 0 files unresolved

  $ hg mv a a2
  $ hg up
  note: possible conflict - a was renamed multiple times to:
   a2
   a1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg ci -m2

  $ touch a
  $ hg ci -Am3
  adding a

  $ hg mv a b
  $ hg ci -Am4 a

  $ hg ci --debug --traceback -Am5 b
  committing files:
  b
  warning: can't find ancestor for 'b' copied from 'a'!
  committing manifest
  committing changelog
  committed changeset 5:83a687e8a97c80992ba385bbfd766be181bfb1d1

  $ hg verify
  checking changesets
  checking manifests
  crosschecking files in changesets and manifests
  checking files
  4 files, 6 changesets, 4 total revisions

  $ hg export --git tip
  # HG changeset patch
  # User test
  # Date 0 0
  #      Thu Jan 01 00:00:00 1970 +0000
  # Node ID 83a687e8a97c80992ba385bbfd766be181bfb1d1
  # Parent  1d1625283f71954f21d14c3d44d0ad3c019c597f
  5
  
  diff --git a/b b/b
  new file mode 100644

http://bz.selenic.com/show_bug.cgi?id=4476

  $ hg init foo
  $ cd foo
  $ touch a && hg ci -Aqm a
  $ hg mv a b
  $ echo b1 >> b
  $ hg ci -Aqm b1
  $ hg up 0
  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ hg mv a b
  $ echo b2 >> b
  $ hg ci -Aqm b2
  $ hg graft 1
  grafting 1:5974126fad84 "b1"
  merging b
  warning: conflicts while merging b! (edit, then use 'hg resolve --mark')
  abort: unresolved conflicts, can't continue
  (use hg resolve and hg graft --continue)
  [255]
  $ echo a > b
  $ echo b3 >> b
  $ hg resolve --mark b
  (no more unresolved files)
  $ hg graft --continue
  grafting 1:5974126fad84 "b1"
  warning: can't find ancestor for 'b' copied from 'a'!
  $ hg log -f b -T 'changeset:   {rev}:{node|short}\nsummary:     {desc}\n\n'
  changeset:   3:376d30ccffc0
  summary:     b1
  
  changeset:   2:416baaa2e5e4
  summary:     b2
  
  changeset:   0:3903775176ed
  summary:     a