brisbane: initial cut at a mergeline cache

[Ian Clatworthy]

Matthew D. Fuller wrote:

> Actually, I find it interesting that you [Ian] feel so strongly that
> way, in view of you just championing and making the change for log
> --long to not show merge revs by default.  That's based on the POV
> that considers "what happened on this branch" to be the most important
> data to view most of the time, and numbering the revs based on when
> they appeared in this branch actually fits far better with that than
> numbering them based on when they departed.

Firstly, I was definitely having a grumpy day then and
I apologize to everyone, particularly Robert, for coming across so
heatedly. :-(

To answer your question ...

Maybe I spent too long using sccs, rcs and cvs and origin-based
numbering just reflects the approach used there? :-(

I don't disagree that knowing when something landed is useful.
But in the good old days, a number like 300.3.55 also said a lot
about what was *not* in that revision if the mainline was now up
to 400 say. Then again, those were the days when everyone avoiding
merging like the plague because it was just so damn painful.
Maybe the origin means a lot less semantically these days?

My broader point was that we ought to have a UI-based reason
for changing the numbering scheme, if we're going to. They
make plenty of sense to me and picking a different scheme *just*
because we can't make the current one perform seems to be putting
the cart before the horse. If we just want a meaningless string,
let's use a sha1 like the competition. :-)

I also feel a sense of pride that our numbering isn't meaningless.
Changing it for no UI benefit would only add fuel to the
"Bazaar isn't stable and in a continuous state of churn" fire.

FWIW, I'm going to add the mergeline cache to a plugin. Those of
us that like it can then use it, test it and refine it until
there's consensus, if ever, about adding something along those lines
into the core.

Ian C.