brisbane: initial cut at a mergeline cache

[Andrew Bennetts]

Ian Clatworthy wrote:
[...]
> Another option suggested is to change the numbering scheme altogether so
> that x and y are related to where the branch gets merged into, not where
> the branch originated from. I'm strongly against this - the current scheme
> makes the most conceptual sense IMNSHO. We *can* make the current scheme
> perform well - it just needs a small cache giving fast lookups for
> revisions in recently added merges.

Actually, I don't find the current scheme particularly helpful in my
day-to-day use.  When I'm examining history I'm much more interested in when
something landed than when something was branched.  So when annotate or log
tells me something happened in 100.2.3 I get a bit frustrated because at
that point the revno could be telling me which mainline revision that change
landed in, but instead it's telling me something else that doesn't help me.

The other thing I do with dotted revnos is treat them as opaque handles to
feed to e.g. "bzr diff -c".  For that purpose it doesn't matter how they are
assigned (so long as they are unambiguous, of course).

So I at least probably wouldn't mind if the dotted revno scheme changed
(although the flux in user experience would be extremely unfortunate, so from
that perspective I would be reluctant).

-Andrew.