brisbane: initial cut at a mergeline cache

[Alexander Belchenko]

Andrew Bennetts пишет:
> Alexander Belchenko wrote:
> [...]
>> 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?
> 
> The problem with caches is they aren't necessarily the best answer.

What is the best answer then? Format zoo may be?

[skip]

You have explained caches ingrained directly in the .bzr metadata,
without this "caches" bzr won't work at all.

I'm talking about additional optional data that helps to improve known
performance problems. Because such caches are optional, they can be used
only for local operations.

> So we're not against caches.  But they are just one possible solution,
> and there may be others with a more desireable set of tradeoffs.  That's
> all.

Reading Robert's mails I have strong impression that core devs against caches
as optional data.

The problem with annotations after knit->pack watershed known for 1.5 year.
And so?

Sorry, but I don't believe that optional data caches won't help for
*local* operations.