[PATCH 2 of 2 STABLE] log: copy the way of ancestor traversal to --follow matcher (issue5376)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Sep 27 10:08:33 EDT 2016



On 09/24/2016 07:59 PM, Jun Wu wrote:
> Thanks for the clean fix! I was trying a different approach but cannot get
> it right easily. These patches should be the correct fix. Marked
> Pre-Reviewed.
>
> A tricky case could be when multiple files are followed, for example:
>
>   $ hg init repo
>   $ cd repo
>   $ for i in 1 2; do
>   >   echo $i >> a
>   >   hg commit -A a -m $i
>   > done
>   $ hg update 0 -q
>   $ echo 2 >> a
>   $ echo 1 > b
>   $ hg commit -A b -A a -m '2 with b' -q
>   $ hg update 1 -q
>   $ echo 1 > b
>   $ echo 1 > a
>   $ hg commit -A b a -m 'b'
>   $ hg merge 2 -q
>   $ echo 1 > b
>   $ hg commit -m merge
>   $ hg log -G -p -T '{rev}:{node|short} {desc}'        # more patches
>   $ hg log -G -p -T '{rev}:{node|short} {desc}' -f a b # less patches
>
> At first sight, it seemed wrong to output less patches for the second
> command. But after a second thought, I believe showing less patches is the
> sane and desired behavior.
>
> - off topic -
>
> By the way, I just encountered an _adjustlinkrev related perf issue when
> working on fastannotate internally. introrev (_adjustlinkrev) can take up
> seconds (and sadly it just returns ctx.linerev() most of the time). Seconds
> is unacceptable comparing with the annotate logic which only takes tens of
> milliseconds.

Did you check that that the ancestry context where properly inherited 
from one check to another, this helps with the cost of adjustlinkrev.

> I think a stupid way to make it better is to have a map of {fctxnode:
> [linknode]}. To make the map small, it only stores entries where
> len([linknode]) > 1. The challenge would be how to keep the map up-to-date.

A smaller step would be to have a fast way to know if a fnode is used 
more than once. We can skip linkrev adjustment for anything with only 
one entry.

A "multiple entry flag" have this interesting similarity with other 
proper with are considering bitmap for: "public", "obs". It is a 
"forward only" property and we could reuse transaction safe logic for 
all of them.


Building a very basic version of this (eg: no cache invalidation, simple 
json on disk) would be a good way to get some number and see how much it 
actually improves performance.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list