bzr-revnocache can now cache the merge graph

[Ian Clatworthy]

John Arbash Meinel wrote:
> Ian Clatworthy wrote:

> So what would end up in the cache, something like:
> 
> 3943.4 1 5 john at arbash-meinel.com-20090120201745-gkvsfuhc9tf7m1bm
>   john at arbash-meinel.com-20090116221614-k8su03l5d22tq6iv
> 
> 
> I guess my question is "mergerevno" the revno this 'line' was merged
> into (3949), or is it the prefix on the revisions themselves (3943.4)

It's 3943.4.

> What is last, join, first and split?

last is rev_id(3943.4.N) where N=5 in this case.
join is rev_id(3949).
first is rev_id(3943.4.1)
split is lefthand_ancestor(first).

We can get to the latter two by walking so there's no need to store
them. After all we don't store first_rev_id for the mainline. OTOH,
we'll known them from walking iter_merge_graph() so there's little
additional upfront cost.

So think of the mergeline cache as extending (last_revno, last_revid)
beyond the mainline (last_revno = length = N). Just as it's fast to
update the last_revision_info data incrementally on commit, I think
we could cheaply update the mergeline cache on a merge commit,
particularly if we left out first & split. (Then again, I suspect we
need to know first and split anyhow to calculate the mergerevno?)
And it will make converting revno => rev-id - a core requirement of
our UI - equally fast for non-mainline in the future as it is for
mainline today.

For what's it worth, once we know that conversion for a revno
specified on the command line, we know the inverse for that rev-id.
So "log --no-include-merges -rx.y.N" can be as fast as
"log --no-include-merges -r-1".

Make sense?

Ian  C.