comparison tests/test-mv-cp-st-diff.t @ 42211:20fce2742399

tests: slightly modify a linkrev test to prepare for expanding it

The test case checks that the copy tracing code doesn't get confused
by linkrevs when walking a file's ancestors. This patch chnages the
test slightly so a second commit is grafted, thus producing a second
"bad" linkrev. I'll use this in the next patch to demonstrate a bug.

Differential Revision: https://phab.mercurial-scm.org/D6321

42210:390ec72b8ea4

Make a simple change

  $ echo change > f
  $ hg ci -m 'change f'

Make a second branch, we use a named branch to create a simple commit
that does not touch f.

  $ hg up -qr 'desc(empty)'
  $ hg branch -q dev
  $ hg ci -Aqm dev

Graft the initial change, as f was untouched, we reuse the same entry and the
linkrev point to the older branch.

  $ hg graft -q 'desc(change)'

Make a rename because we want to track renames. It is also important that the
faulty linkrev is not the "start" commit to ensure the linkrev will be used.

  $ hg mv f renamed
  $ hg ci -m renamed

  $ hg log -G -T '{rev} {desc}'
  @  4 renamed
  |
  o  3 change f
  |
  o  2 dev
  |
  | o  1 change f
  |/
  o  0 empty f
  

The copy tracking should still reach rev 2 (branch creation).
accessing the parent of 4 (renamed) should not jump use to revision 1.

  $ hg diff --git -r 'desc(dev)' -r .
  diff --git a/f b/renamed
  rename from f
  rename to renamed

  +change

Check debug output for copy tracing

  $ hg status --copies --rev 'desc(dev)' --rev . --config devel.debug.copies=yes --debug
  debug.copies: searching copies from a51f36ab1704 to 7935fd48a8f9
  debug.copies: search mode: forward
  debug.copies:    looking into rename from a51f36ab1704 to 7935fd48a8f9
  debug.copies:      search limit: 2
  debug.copies:      missing file to search: 1
  debug.copies:        tracing file: renamed
  debug.copies:          rename of: f
  debug.copies:          time: * seconds (glob)
  A renamed
    f

42211:20fce2742399

Make a simple change

  $ echo change > f
  $ hg ci -m 'change f'

Make a rename because we want to track renames. It is also important that the
faulty linkrev is not only the "start" commit to ensure the linkrev will be
used.

  $ hg mv f renamed
  $ hg ci -m renamed

Make a second branch, we use a named branch to create a simple commit
that does not touch f.

  $ hg up -qr 'desc(empty)'
  $ hg branch -q dev
  $ hg ci -Aqm dev

Graft the initial change and the rename. As f was untouched, we reuse the same
entry and the linkrev point to the older branch.

  $ hg graft -q 'desc(change)'
  $ hg graft -q 'desc(renamed)'

  $ hg log -G -T '{rev} {desc}'
  @  5 renamed
  |
  o  4 change f
  |
  o  3 dev
  |
  | o  2 renamed
  | |
  | o  1 change f
  |/
  o  0 empty f
  

The copy tracking should still reach rev 3 (branch creation).
accessing the parent of 5 (renamed) should not jump use to revision 1.

  $ hg diff --git -r 'desc(dev)' -r .
  diff --git a/f b/renamed
  rename from f
  rename to renamed

  +change

Check debug output for copy tracing

  $ hg status --copies --rev 'desc(dev)' --rev . --config devel.debug.copies=yes --debug
  debug.copies: searching copies from a51f36ab1704 to 1f4aa1fd627b
  debug.copies: search mode: forward
  debug.copies:    looking into rename from a51f36ab1704 to 1f4aa1fd627b
  debug.copies:      search limit: 3
  debug.copies:      missing files to search: 1
  debug.copies:        tracing file: renamed
  debug.copies:          rename of: f
  debug.copies:          time: * seconds (glob)
  A renamed
    f