RFC get_revision_graph

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> The way it is implemented in packs (ATM) is that for each node, you
> query the
> index for the parents of the node. Then you query the index again for the
> parents to see if they are present (so you can remove ghosts). Then you
> step and
> do the same thing again.

Couldn't we just avoid the second query?  When we step, we'll quickly
find out which of the parents are present anyhow.

> Which means that you query the index at least 2x for every node (even
> more for
> nodes that have a lot of children since the parent nodes get queried
> each time).
> Also, the index is written to not cache the parent information, so it
> requires
> bisecting into the in-memory nodes again. We have a
> CachingParentProvider, but
> that works at a higher level.
> 
> I thought there might be 2 possible resolutions.
> 
> 1) Redefine (or create a new api) that gives the revision graph, only it
> includes ghosts. That way you don't have to check if parents exist.
> 
> 2) Push the revision_graph down a level, or push the ghost filtering up
> a level.

gannotate uses the revision graph solely for generating revnos.  It
might be better to implement tsort.merge_sort on top of Graph.  That
would mean more direct use of the Graph API, so we wouldn't necessarily
need caching, but it would also allow us to use caching if necessary.

We hope to optimize revno generation so that it doesn't require
whole-history operations, so having it already using Graph is a step in
the right direction.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvLnt0F+nu1YWqI0RAkuSAJ9tQ1IbflF8Wsdm6ixxqCy7fsygigCfRRzR
zSI/rdWKsHDKwDA69YNm1vs=
=y+Wd
-----END PGP SIGNATURE-----