trac-bzr performance (was: Re: Introduce generator for lefthand branch history)

[Martin von Gagern]

Aaron Bentley wrote:
>> I fear so. On the other hand, there are quite a lot of parts in trac-bzr
>> which call Repository.get_ancestry
> 
> This kind of thing is why I abandoned trac-bzr.  I think Trac has a
> serious impedence mismatch with bzr.  Any operation that scales with
> whole history is bad.  That's why we have iter_reverse_revision_history,
> and why _lefthand_history is considered "evil".
> 
>> I assume the cost for the generation of dotted revision
>> numbers is on a similar scale. Therefore it should be possible to
>> achieve simple calculations on the complete parent map in a comparable
>> timeframe. 
> 
> Yes, but it does not scale.

I agree that operations scaling by whole history should be avoided if at
all possible. I'm not sure this is inherently impossible with Trac. I'm
planning to get rid of Repository.get_ancestry in as many places as
possible, maybe all.

On the other hand, I wonder how other apps cope with these issues.
Loggerhead for example uses dotted revnos as well, and also prints
information about when a rhs changeset was merged into mainline. Haven't
looked at the sources yet but I can't help to wonder how these things
are possible without potentially inspecting the whole parent map.

Or is it that in theory the whole history would need to be inspected,
but that in practice the modifications users are likely interested in
are somewhere near the top of the tree and therefore can be answered
cheaply, while only ancient revisions would require a deeper and more
expensive look?

Any pointers at relevant bzr api functions would be appreciated!

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091127/a76fbfd2/attachment.pgp