[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