[MERGE] Branch.iter_merge_sorted_revisions

[Ian Clatworthy]

I now think this patch is ready to land. This version
simplifies the semantics of 'forward' to be appropriate
to this API layer, i.e. forward is simply the opposite
to reverse, not some fancy UI-specific ordering that may
change over time.

Vincent has raised the issue of 'reverse' vs 'forward'
and would 'backward' vs 'forward' be better direction
names? I agree with his thinking but I've left it as
'reverse' to be consistent with other API names, e.g.
iter_reverse_revision_history. Sometimes consistency
is more important than strict semantics. :-)

There is also the issue of whether a last-revision
parameter ought to be supported or not. That's clearly
important when sorting an arbitrary graph but I think
it's unnecessary in the context of a branch method.
If we do add it, my feeling it that it ought to mean
"sort the full graph then skip to it before reporting
results" as I've explained in the comments. Either way,
a don't think that parameter is required in this
initial version of the API.

Once this API is in place, we can avoid calculating the
full graph multiple times as can happen quite
easily now (e.g. once to build the revid->revno map
and again in the core logic of commands like log and
missing). It will also allow plugins like revnocache
to provide a cached version of the revision graph,
greatly speeding up log (and other commands) on large
projects.

Ian C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iter_merge_sorted_revisions-2.patch
Type: text/x-diff
Size: 11590 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090122/c435fa1f/attachment.bin