view tests/test-mq-qpush-fail @ 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 51c29aec0b75
children 801cacf46e62
line wrap: on
line source

#!/bin/sh

# Test that qpush cleans things up if it doesn't complete

echo "[extensions]" >> $HGRCPATH
echo "mq=" >> $HGRCPATH

hg init repo
cd repo

echo foo > foo
hg ci -Am 'add foo'

touch untracked-file
echo 'syntax: glob' > .hgignore
echo '.hgignore' >> .hgignore

hg qinit

echo '% test qpush on empty series'
hg qpush

hg qnew patch1
echo >> foo
hg qrefresh -m 'patch 1'

hg qnew patch2
echo bar > bar
hg add bar
hg qrefresh -m 'patch 2'

hg qnew bad-patch
echo >> foo
hg qrefresh

hg qpop -a

python -c 'print "\xe9"' > message
cat .hg/patches/bad-patch >> message
mv message .hg/patches/bad-patch

hg qpush -a && echo 'qpush succeded?!'

hg parents

echo '% bar should be gone; other unknown/ignored files should still be around'
hg status -A