[MERGE] Branch.iter_merge_sorted_revisions

[John Arbash Meinel]

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

Ian Clatworthy wrote:
> 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.
> 

If we are reworking things, I would make it "exclude" and then I would
change the meaning of log "-r X..Y" to be "show me everything in Y which
is *not* in X". Which would also be exclusive, and then also matches
with things like "bzr diff -r X..Y". It also would make it clearer what
"bzr log -c X" should show versus "bzr log -r X".

I would only do that if we are really overhauling log, though.

John
=:->

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

iEYEARECAAYFAkl8bi8ACgkQJdeBCYSNAANMmQCgiLmF1RQJOhar3bgapptAF50T
nBQAoNADnxTJgtJYW+21hMChIyJbE5+E
=m8ID
-----END PGP SIGNATURE-----