[MERGE/RFC] Branch.merge_sorted_revisions

[Ian Clatworthy]

John Arbash Meinel wrote:

> Ultimately I don't think an api like this will "scale". Because it
> always describes the full history of revisions. I think it might be okay
> as a stepping point (and certainly works better with your revno-cache),
> but it seems like you would want something that allows you to give a
> subset via some fashion. Not to mention being able to iterate forward or
> reverse.
> 
> So if it is a step towards something more efficient, it is probably ok,
> but I wouldn't really want to introduce an api that requires O(history)
> as part of its definition.

So what if I make it

  iter_merge_sorted_revisions(direction='reverse')

?

In the first cut, I'd like to leave out subsetting because:

* it will complicate caching

* the way of nominating a starting point (sequence # vs
  revision-id vs revno) could restrict internal
  implementation options (at a guess)

* we can always add it later.

Ian C.