speed up hg log --patch Changing dodiff to read the manifest/changelog for node1 before calling repo.update allows us to take advantage of the revlog revision cache. Before this patch and my previous "speed up hg log --debug" patch, when using hg log -p to display three revisions (A, B and C), dodiff and repo.changes would end up reading the manifests in this order: B A B A C B C B With both patches, this order becomes: A A B B B B C C (This considers only dodiff and repo.changes. I'm not sure how other parts of hg log enter the picture.) The speed up will depend on the revisions being displayed. (All "before" times already have my previous "speed up hg log --debug" patch applied.) hg repo (tip = 414e81ae971f). hg log -p before after real 0m50.981s 0m45.279s user 0m47.930s 0m42.560s sys 0m2.526s 0m2.523s output size: 6917897 bytes kernel repo (tip = 9d4e135960ed). hg log -p -l64 before after real 2m14.995s 1m45.025s user 2m9.509s 1m33.900s sys 0m3.663s 0m2.942s output size: 31497621 bytes same kernel repo. hg log -p -l64 -r c84c2069592f:0 before after real 1m48.045s 1m0.076s user 1m44.094s 0m58.492s sys 0m2.603s 0m1.103s output size: 197983 bytes c84c2069592f was the tip of a 10 day old kernel repo that I had lying around and was where I first tested this patch. For some weird coincidence it's also a place where the patch makes a huge difference.

#!/bin/sh

set -e
set -x

# skip commit logs
HGMERGE=tkmerge; export HGMERGE
EDITOR=true; export EDITOR

rm -rf m m1 m2
mkdir m
cd m

echo "m     this  that"
echo "this" > a
echo "that" > b
hg init
hg addremove
hg commit
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ..
echo "m2    this  that "
mkdir m2
cd m2
hg branch ../m
hg checkout
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m
echo "m     this1 that "
echo "this1" > a
hg commit
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ..
echo "m1    this1 that "
mkdir m1
cd m1
hg branch ../m
hg checkout
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m1
echo "m1    this1 that1"
echo "that1" > b
hg commit
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m2
echo "m2    this  that2"
echo "that2" > b
hg commit
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m1
echo "m1:m2 this1 that1 that2"
hg merge ../m2 # b should conflict, a should be fine
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m2
echo "m2    this2 that2"
echo "this2" > a
hg commit
echo "a:" `hg dump a` "b:" `hg dump b`
echo

cd ../m2
echo "m2:m this12 that2"
hg merge ../m # a should conflict, b should be fine
echo "a:" `hg dump a` "b:" `hg dump b`
echo

# now here's the interesting bit
# if we choose ancestor by file, no conflicts
# otherwise we've got two equally close ancestors, each with a conflict
# if we go back to the root, we'll have both conflicts again
echo "m2:m1 this12 that12"
hg merge ../m1 # should be clean
echo "a:" `hg dump a` "b:" `hg dump b`
echo