brisbane: initial cut at a mergeline cache

[Alexander Belchenko]

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. :-(

I don't think you are wrong in the end.

Claims that bzr can be fast -- it's all theory for me.
Claims that bzr will be fast sometimes -- I don't it. I don't have time machine
to go in the future, do all my today work and go back. I need some solution
today, not in 2010 or 2020 year.

There is many cases where caches may help. Log, annotations.
I'm just don't understand why core devs don't want to implement caches.
It's too hard?

> 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?

To answer this question you need to answer first: who, when, and why for
anyone need to know origin? Should it be revno, or it is good enough to know revid?

> 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. :-)

It does not help, you know this. If you switch to sha1 you need a cache
to map sha1->revid to avoid recalculating of sha1 for every revision
in the history.

> 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.

I have a good use case for dotted revno based on merge point:

When you look at annotations you see dotted revno like 213.4.5.
And what? In most cases it's more useful to know where this revision
was merged. Because then user can do branch from merge point,
e.g. to find (bisect) some bug or odd code.

I've asked once in the past: if I know dotted revno, how can I find
revision where it merged? The answer was: run log --long|less and then
search for this revno via less, and then scroll up. Huh?

> 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.
> 
>