[rfc] [patch] speeding up bzr log with a tree delta iterator

[John Arbash Meinel]

Denys Duchier wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
> 
> 
>>I'm curious why we stopped using 'deltas_for_log_forward' and
>>'deltas_for_log_reverse.' Those did exactly what you are doing with your
>>iterator (kept track of the previous entry, and computed the appropriate
>>delta).
> 
> 
> I didn't know they existed. they seem to _want_ to do something similar, but
> they look wrong - what is this:
> 
>                   this_tree = EmptyTree(branch.get_root_id())

At one point, we actually had tree root ids. Which meant that every tree
root should have a unique identifier (similar to the identifier for a
directory or file).

At that time, comparing an EmptyTree to the first revision would find
the change that the tree root went from being None to having a value, so
the above code passed the root id to the EmptyTree, so that the
difference would not occur.

The root_id concept got severely damaged in some of the other changes.
Though we are probably going to put it back in. (But EmptyTree may not
need a root_id at that point).

> 
> business?  I don't understand this code... but mine seems clear (to me, that is,
> of course).
> 
> Also, I tried to provide a minimally invasive patch that closely followed and
> respected the semantics of the code that was actually used.
> 
> I am fine with changing it, but you guys have to decide what you want.
> 
> Keep in mind that my patch does the same as before only much more efficiently.
> The abstraction can always be revised later, but we can have the performance
> improvement today :-)
> 
> Cheers,
> 
> --Denys

I would be happier if this wasn't part of Branch, and instead was inside
delta.py
I don't know why the functions delta_* were no longer used.

I think this happened when we switched to having the LogFormatter class.
At least that is as near as I can tell. The actual changes claim to have
come from:
abentley at panoramicfeedback.com-20050811205739-dc1988c004f9503e

Whose only comment is:
merged mbp at sourcefrog.net-20050817233101-0939da1cf91f2472

Which was back before merge actually marked merges. So the actual
per-line ancestry was lost in the conversion to weave files.

Which also means this was done a really long time ago, and nobody seemed
to notice the performance degradation.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060117/0abd7bdb/attachment.pgp