Mercurial > hg
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