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

[Aaron Bentley]

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

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.

> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHxYLG0F+nu1YWqI0RAoAFAJ0VwKyU4AmOOFIk5W5dIj+T4STGAgCaA6xj
oUHJvEm1YEZzRK3Lisj1iK0=
=fbZK
-----END PGP SIGNATURE-----