[MERGE] add stop_rule to Branch.iter_merge_sorted_revisions()

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> John Arbash Meinel wrote:
>> Ian Clatworthy wrote:
>>
>> ...
>>
>>>> In this specific case I was thinking:
>>>>
>>>> parents = get_parent_map([revision])[revision]
>>>>
>>>> Where the length of parents can certainly be > 1.
>>> Thinking out loud, I wonder if stopping at any parent ought to be explicitly
>>> supported, i.e. instead of having "with-merges" we had "include-until-parent"?
>>> That way we'd be matching against revision-ids instead of relying on any
>>> nuances of the depth calculation algorithm. I'm pretty sure
>>> include-until-parent makes with-merges redundant doesn't it?
>>> Ian C.
>>
>> I would think so, and yes, I would probably prefer that as well. Though
>> I haven't really worked out the specifics to be positive on this.
> 
> Hmm, playing with this idea, it seems that stopping at any parent is
> equivalent to 'include'. I've therefore kept the API as it was but
> reimplemented 'with-merges' to check for the left-hand parent, rather
> than relying on the depth.
> 
> Updated patch attached. Is this acceptable now?
> 
> Ian C.
> 

Ultimately I feel like making "bzr log -r X..Y" be exclusive the way
"bzr diff -r X..Y" is, would be a better solution, and doesn't require
"with-merges". However, if we have the api, we can always just not use
it if we decide to change the UI.

BB:approve

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmEsy4ACgkQJdeBCYSNAAOhYgCggtPwZOOwZVlQhDGqrWPeNN2y
pEYAoJ9Vbt4DIv3VsCqb72RxLlQQv3eb
=BFaP
-----END PGP SIGNATURE-----