[MERGE] make it possible to pass NULL_REVISION as the branch_tip parameter to merge_sort
John Arbash Meinel
john at arbash-meinel.com
Wed Feb 27 15:38:03 GMT 2008
-----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-----
More information about the bazaar
mailing list