brisbane: initial cut at a mergeline cache

[Ian Clatworthy]

Robert Collins wrote:
> On Mon, 2009-03-30 at 14:53 +1000, Ian Clatworthy wrote:
>> Robert Collins wrote:
>>
>>> Don't update on read operations, its not safe, and unlike dirstate there
>>> is no need to do so as only write-locked operations can change the state
>>> it would cache.
>> I don't think that's an option. The whole basis for the design is *not*
>> to impact write operations in any way, just save some key data calculated
>> during the first read operation, making subsequent ones are faster.
> 
> Then I think the design is definitely wrong and needs reevaluation. This
> data is known during write, and reads outnumber writes immensely;
> penalising the most common operation is a serious issue. Or does the
> cache write to somewhere other than the branch? 

It's not obvious to me that this data is known during writes. When we
merge, we don't know the revnos of those merged revisions without
(currently) re-merge-sorting the full graph.

The penalty (0.1s out of 5s) is paid only the first read operation
after the branch tip moves.

Ian C.