[MERGE] make it possible to pass NULL_REVISION as the branch_tip parameter to merge_sort

[John Arbash Meinel]

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

Aaron Bentley wrote:
| John Arbash Meinel wrote:
|> I'm okay with this patch, as it works around a bug. What I would *like*
|> is to
|> have our apis be more consistent.
|
| Well, Graph already provides iter_topo_order.  I'd prefer not to change
| get_revision_graph in backwards-incompatible ways.  get_revision_graph
| is a whole-history operation, and therefore evil.  I'd deprecate it if I
| could.

Sure, though iter_topo_order is topo_sort order and not merge_sort order. Plus
it doesn't return revision numbers.

|
|> If 'branch.last_revision()' can return
|> NULL_REVISION, then branch.repository.get_revision_graph(NULL_REVISION)
|> should
|> include NULL_REVISION in the returned dictionary.
|> We can just have merge_sort(get_revision_graph()) start counting at 0,
|> so that
|> NULL_REVISION == 0, and the rest count up from there.
|
| Weren't we just recently talking about moving merge_sort onto Graph?
|
| Aaron

I don't remember a discussion on that, but yeah, that would be reasonable.

My patch also introduces Graph.iter_ancestry() which is effectively
get_revision_graph() using an iterator over get_parent_map. And then
get_revision_graph() is just a filter over it to remove the NULL_REVISION
discrepancies. (And filter out ghost nodes, because that is also part of the
get_revision_graph() api.)

get_revision_graph is a great candidate for being deprecated.

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

iD8DBQFHxYPbJdeBCYSNAAMRAniIAKCerWRPsfI8G9TakgIdtOXejYbKkACfavRZ
EdUir72NaNjoIz6h8TYa2SM=
=Q+tG
-----END PGP SIGNATURE-----