Can "bzr annotate" be sped up?

[vila]

>>>>> Alexander Belchenko <bialix at ukr.net> writes:

    > 17.06.2011 14:04, John Arbash Meinel пишет:
    >> 1) Annotate in 'reverse' mode. Forward mode is a bit more obvious. You
    >> start at a rev, mark all lines as 'modified in rev 1'. Then grab the
    >> second rev, and lines that match are left alone, lines which are new are
    >> marked 'rev2'. Then on to rev3, etc.
    >> 
    >> In reverse mode, you start at rev3 and mark all lines as 'unknown'. Then
    >> you compare with rev2. All lines that match are left as 'unknown', new
    >> lines in rev3 are marked 'rev3'. That isn't particularly hard, the
    >> trickier part is dealing with merge-parents. (Lines are new in the
    >> current text vs the first parent, but that is because they came from the
    >> second parent.)

    > Very interesting, thanks for sharing it. I think reverse mode is very
    > important, esp. if the system want to support history horizons. Then
    > you don't have access to older revisions, so reverse order should work
    > better, IMO.

Agreed.

But I'll go even further. The two  main contenders so far seem to be:

1) Annotating in reverse order

2) Restricting annotations to a line range.

I think in most of the cases line range won't work well as you need the
whole file to track the range. This can be bound to the highest line but
I don't expect a lot to be gained this way (even if you can limit the
processing you still need to process a significant part of the file).

Reverse order in contrast may be designed to work asynchronously:

- start with the file current content with no annotations,

- provides the annotations as they are discovered.

This requires collaboration from the client side but since the user is
generally interested by the most recent changes the end result will be
available sooner. And while the user is analyzing the first annotations,
the older ones can be provided later, up to the least interesting ones.

    Vincent