API question: ancestors of B that are not ancestors of A

Matt Mackall mpm at selenic.com
Wed Dec 9 16:34:23 CST 2009


On Wed, 2009-12-09 at 17:29 -0500, Greg Ward wrote:
> On Wed, Dec 9, 2009 at 4:48 PM, Matt Mackall <mpm at selenic.com> wrote:
> >> But 1) I'm working in Python, not shell, so it's easier to make calls
> >> to the Mercurial API and 2) my repository has 104,000 changesets, so
> >> "--rev B:0" takes a while (~60 sec without --follow, ~130 sec with
> >> --follow).
> >
> > You might find that -q makes it a lot faster (it just uses the index).
> 
> That was with -q.  It was also a near-worst case for that particular
> formulation: comparing a near-tip revision to tip:
> 
>   $ time hg log --follow -q -rtip:0 -P 104325
>   104339:cf603b1018fb
>   104336:9d06300772ae
>   [...several hundred more...]
>   101660:7f617f192df1
>   hg log --follow -q -rtip:0 -P 104325  128.85s user 0.50s system 98%
> cpu 2:11.68 total

Hmm, that's odd. We can probably improve that. How long do 'hg log -q
> /dev/null' take?

> > I think the simplest way to do it is something like (untested):
> >
> > cl = repo.changelog
> > a = set(cl.ancestors(A))
> > b = set(cl.ancestors(B))
> > revs = b - a
> 
> Holy kabunga that goes fast.  Much better, thank you!  Not sure if the
> loss of order matters to me, but I'll figure something out.  I suppose
> I can just sort by revnum to get *a* topo sort, even if it's not the
> prettiest topo sort.
> 
> Err, I'm a little embarassed to ask such a newbie question after I've
> been hanging around here this long, but: does revlog keep the entire
> index in memory?

We've got two modes: full and lazy. Most indexes are opened in 'full'
mode unless they're quite large, in which case they'll open in 'lazy'
mode. Lazy mode is good enough for things like tip and other simple
queries.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list