~bzr-pqm/bzr/bzr.dev : changes

~bzr-pqm/bzr/bzr.dev » Changes from revision 4593.5.43

Rev	Summary	Authors	Date
4593.5.43	The api for topo_sort() was to allow a list of (key, value) The api for topo_sort() was to allow a list of (key, value) or a dict. So we need to cast things back into a dict for KnownGraph.	John Arbash Meinel	15 years ago
4593.5.42	Turns out that some code assumed passing NULL_REVISION to me... Turns out that some code assumed passing NULL_REVISION to merge_sort always was fine, and now that we are using 'keys' it was passing (NULL_REVISION,) for now, that should be ok.	John Arbash Meinel	15 years ago
4593.5.41	Fix a few test cases that assumed topological sorting was st... Fix a few test cases that assumed topological sorting was stable.	John Arbash Meinel	15 years ago
4593.5.40	Clean up NEWS a bit, and add items for the improvements with... Clean up NEWS a bit, and add items for the improvements with log, etc.	John Arbash Meinel	15 years ago
4593.5.39	Merge bzr.dev 4624 in preparation for NEWS Merge bzr.dev 4624 in preparation for NEWS	John Arbash Meinel	15 years ago
4593.5.38	Remove import deque per Vincent's request. Remove import deque per Vincent's request.	John Arbash Meinel	15 years ago
4593.5.37	Finish implementation tests. Finish implementation tests.	John Arbash Meinel	15 years ago
4593.5.36	a few more implementations of the interface. a few more implementations of the interface.	John Arbash Meinel	15 years ago
4593.5.35	Start working on a per-vf implementation test of find_ancest... Start working on a per-vf implementation test of find_ancestry. Turns out we need to do a bit more implementation to get that working. We also need to implement the find_ancestry() code on the Builder objects.	John Arbash Meinel	15 years ago
4593.5.34	Change the KnownGraph.merge_sort api. Change the KnownGraph.merge_sort api. Instead of being a tuple api, it is now an Object api. TIMEIT testing at least seems to say that _MergeSortNode.key is no slower than using a tuple. Allocating the nodes is also not much slower (especially since we already needed them.) In the end it makes for an api which, IMO, is much easier to use, so since performance isn't impacted, it is worth switching. Also, determined that we needed to implement the new get_known_graph... on the weave code.	John Arbash Meinel	15 years ago
4593.5.33	Late import tsort because it causes an import cycle. Late import tsort because it causes an import cycle.	John Arbash Meinel	15 years ago
4593.5.32	With the new api, we don't return 'sequence_number' anymore. With the new api, we don't return 'sequence_number' anymore. Nothing ever used it anyway, and branch.iter_merge_sorted... was stripping it out. No need to do the extra busy work.	John Arbash Meinel	15 years ago
4593.5.31	Fix bzrlib.missing to not directly load the graph, etc. Fix bzrlib.missing to not directly load the graph, etc. Look at bzrlib.annotate, but it needs to inject a node into the graph, which isn't supported yet.	John Arbash Meinel	15 years ago
4593.5.30	Move the topo_sort implementation into KnownGraph, rather th... Move the topo_sort implementation into KnownGraph, rather than calling back to it.	John Arbash Meinel	15 years ago
4593.5.29	Remove the gc enable/disable code. Remove the gc enable/disable code. It doesn't seem to have a specific benefit in real world testing. Though a global gc.disable speeds up bzr log bzr.dev from 1.1s to 0.9s.	John Arbash Meinel	15 years ago
4593.5.28	Cleanup pass Cleanup pass	John Arbash Meinel	15 years ago
4593.5.27	bit of cleanup passes bit of cleanup passes	John Arbash Meinel	15 years ago
4593.5.26	small cleanup, a bit of comment tweaking. small cleanup, a bit of comment tweaking.	John Arbash Meinel	15 years ago
4593.5.25	Add tests that we detect GraphCycleError Add tests that we detect GraphCycleError Turned out to be quite important, because otherwise KnownGraph.merge_sort() ends up in an infinite loop w/ a GraphCycle. (unlike topo_sort which pretty much just ignores those nodes.)	John Arbash Meinel	15 years ago
4593.5.24	Switch some variables from Py_ssize_t to long Switch some variables from Py_ssize_t to long It turns out that long => PyInt is slightly faster than Py_ssize_t => PyInt because interally PyInt holds a 'long' and in theory Py_ssize_t could be bigger than a long. For what we were doing, we never needed anything bigger than 'long'.	John Arbash Meinel	15 years ago

Older »