groupcompress-optimal not deterministic
Bug #418302 reported by
Robert Collins
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Critical
|
John A Meinel |
Bug Description
The current sort_gc_optimal code relies on topo_sort, which has never been a 'stable' sort. (The old form started with a random node, the new form also depends on the sort order of dicts.)
This means that 'bzr pack' cannot trust that the groupcompress order it computes now was the same as the one used when packing before. So we can't use the ordering on disk to see if things are 'already optimally packed'.
It should be possible to create a stable gc ordering. Either by basing it on something like 'merge_sort' or simply sorting nodes before emitting them.
summary: |
- groupcompress-optimal no longer deterministic + groupcompress-optimal not deterministic |
description: | updated |
Changed in bzr: | |
assignee: | nobody → John A Meinel (jameinel) |
status: | Confirmed → In Progress |
Changed in bzr: | |
status: | In Progress → Fix Released |
milestone: | none → 2.0 |
To post a comment you must log in.
whOn Mon, 2009-08-24 at 20:15 +0000, Robert Collins wrote: optimal not be
> Public bug reported:
>
> Apparently the toposort changes make groupcompress-
> deterministic. This will cause churn - on the same machine even.
John notes that this isn't really a new problem - but it still is a
problem.
-Rob