[MERGE] Branch.iter_merge_sorted_revisions

[Ian Clatworthy]

Ian Clatworthy wrote:
> John Arbash Meinel wrote: 

>> I think it is strictly necessary to avoid having an api that is always
>> O(all_history). I would generally always make it a "revision_id" because
>> that is how 95% of the internals work. In fact, I would consider it
>> should actually be given a start and an end revision id
>> (inclusive/exclusive?)
> 
> Yeah, that makes sense. The moment 'direction' is supported as
> a parameter (and it is now), an efficient implementation needs
> to know the two endpoints. My preference is to make the limits
> inclusive.

It looks like 'inclusive' isn't flexible enough. I'm going to add a
parameter called (something like) stop_rule with values of:

* "exclude" - leave the stop revision out of the result
* "include" - put the stop revision in the result
* "with-merges" - put the stop revision and nested merges in the result.

Any thoughts on the best default? It's currently "include" but
the API has only existed for 24 hours so I'll change it to
"exclude" (say) if we think that's the most common case.

Ian C.