view tests/test-patch @ 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.
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
date Tue, 19 May 2009 16:49:54 +0900
parents 0de7e6e27fe4
children
line wrap: on
line source

#!/bin/sh

cat > patchtool.py <<EOF
import sys
print 'Using custom patch'
if '--binary' in sys.argv:
    print '--binary found !'
EOF

echo "[ui]" >> $HGRCPATH
echo "patch=python ../patchtool.py" >> $HGRCPATH

hg init a
cd a
echo a > a
hg commit -Ama -d '1 0'
echo b >> a
hg commit -Amb -d '2 0'
cd ..

# This test check that:
# - custom patch commands with arguments actually works
# - patch code does not try to add weird arguments like
# --binary when custom patch commands are used. For instance
# --binary is added by default under win32.

echo % check custom patch options are honored
hg --cwd a export -o ../a.diff tip
hg clone -r 0 a b

hg --cwd b import -v ../a.diff