[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:
|> Aaron Bentley wrote:
|> | Well, Graph already provides iter_topo_order.
|
|> Sure, though iter_topo_order is topo_sort order and not merge_sort
|> order. Plus
|> it doesn't return revision numbers.
|
| But merge_sort is built on top of topo_sort, so it should be a simple port.

Um... I'm not sure what you mean. If you look at the internals merge_sort() is
very different, as it uses a MergeSorter, steps through it, etc.
Certainly we could just provide "iter_merge_sort_order()" or something like that.

|
|> | Weren't we just recently talking about moving merge_sort onto Graph?
|> I don't remember a discussion on that, but yeah, that would be reasonable.
|
| Hmm.  I can't find the thread right now, but it was about generating
| dotted revnos for gannotate.  Or maybe I just *meant* to suggest it.
|
|> get_revision_graph is a great candidate for being deprecated.
|
| So everywhere we need a whole-history graph we just do
| dict(Graph.iter_ancestry) ?
|
| Aaron

Something like that. Though iter_ancestry() will return the get_parent_map()
format. (So pointers to (NULL_REVISION,) and ghosts point to ()).

At least hopefully the number of places that "need a whole-history graph" will
be limited.

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

iD8DBQFHxY7MJdeBCYSNAAMRAgTDAKCmytk7klTU0p4pLE7Mr03/8cD0nQCfTNJk
EZFfBnnc1mk6wRfLQvY5WHE=
=7kFb
-----END PGP SIGNATURE-----