Introduce generator for lefthand branch history

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin von Gagern wrote:
> Aaron Bentley wrote:
>> Martin von Gagern wrote:
>> We already have a public, official method for getting the lefthand
>> revision history of a branch: Branch.revision_history.
> 
> That one doesn't take arguments but always generates the history from
> tip. So certainly useful, but not what I requested here.

Sure, but it we were going to provide a public method, it would make
more sense to parameterize Branch.revision_history than to provide a new
method.

> But I started by looking at how Branch.revision_history is implemented
> internally, and that works by using Branch._lefthand_history, which does
> all the work by itself, without delegating to
> Repository.iter_reverse_revision_history.

No, for modern branches, it goes through

BzrBranch8._gen_revision_history
Branch._extend_partial_history
Repository.repository._iter_for_revno
Repository.iter_reverse_revision_history

(For old branches, it just reads the revision-history file.)

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksQBoYACgkQ0F+nu1YWqI3hDQCggGRDP7T6PPpJ30B47t/HfoHX
78sAnRytyya5/2gVoVrjvrCbreuhn3Ih
=Y9Sr
-----END PGP SIGNATURE-----