[MERGE] add stop_rule to Branch.iter_merge_sorted_revisions()

[Ian Clatworthy]

John Arbash Meinel wrote:

> So, the fact that you need to add this complexity makes me feel that the
> api isn't quite what we want.
> 
> For example, if you used an 'exclusive' range, callers could always
> convert that into an inclusive range by doing:
> 
> base=X
> base_parent=get_parent_map([base])
> iter_merge_revisions(start, end=base_parent)
> 
> (grab the parent of the given revision, and do an exclusive search on
> that.)

Right. But keep in mind that the API hides the whole get_parent_map()
stuff from the caller. So forcing them to have to grab one seems more
complex to me than adding a parameter to iter_merge_sorted_revisions().

If *Branch* had a simple first_ancestor() method, then I'd probably be
OK with dropping stop_rule and always making it 'exclude'. But even then,
we'd cover the exclude and with-merges cases but not the include one so
easily. (Martin Albisetti wants include for Loggerhead btw.)

> In fact, I would even consider that we may want to allow multiple stop
> revisions So that you would pass both parents of the revision.

I'd like to know more about this. It sounds a good idea, although it will
certainly make the implementation slightly more complex. Can you give
an example of when this would be useful to a client of the Branch API?

> If you feel like this is still the best way to go, then we can certainly
> do it. I'm mostly suggesting that the simplest api that can get the
> information we need is probably better.

Sure. Thanks for the review & feedback.

Ian C.