view tests/test-empty-group @ 8849:80cc4b1a62d0

compare grep result between target and its parent

I found that typical case is that grep target is added at (*) revision
in the tree shown below.

     +--- 1(*) --- 3
     0
     +--- 2 ------ 4

Now, I expect 'hg grep --all' to show only rev:1 which is first
appearance of target line.

But 'hg grep --all' will tell:

  target line dis-appeared at 3 => 4
  target line     appeared at 2 => 3
  target line dis-appeared at 1 => 2
  target line     appeared at 0 => 1

because current 'hg grep' implementation compares not between target
revision and its parent, but between neighbor revisions in walkthrough
order.

I checked performance of this patch by "hg grep --follow --all
walkchangerevs" on whole Mercurial repo, and patched version could
complete as fast as un-patched one.

#!/bin/sh
#
#  A          B
#
#  3  4       3
#  |\/|       |\
#  |/\|       | \
#  1  2       1  2
#  \ /        \ /
#   0          0
#
# if the result of the merge of 1 and 2
# is the same in 3 and 4, no new manifest
# will be created and the manifest group
# will be empty during the pull
#
# (plus we test a failure where outgoing
# wrongly reported the number of csets)
#

hg init a
cd a
touch init
hg ci -A -m 0 -d "1000000 0"
touch x y
hg ci -A -m 1 -d "1000000 0"
hg update 0
touch x y
hg ci -A -m 2 -d "1000000 0"
hg merge 1
hg ci -A -m m1 -d "1000000 0"
#hg log
#hg debugindex .hg/store/00manifest.i
hg update -C 1
hg merge 2
hg ci -A -m m2 -d "1000000 0"
#hg log
#hg debugindex .hg/store/00manifest.i

cd ..
hg clone -r 3 a b
hg clone -r 4 a c
hg -R a outgoing b
hg -R a outgoing c
hg -R b outgoing c
hg -R c outgoing b

hg -R b pull a
hg -R c pull a