© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
I'll note that the reason we didn't encounter this before is because pre --dev6, doing 'bzr pack' with a single pack file was shortcutted into being a no-op.
I disabled that for --dev6 because for a long time we were experimenting with different compression schemes, etc, and it made it really nice to just do 'bzr pack' to try something new.
I think we could either:
1) Restore the shortcut logic. Though future improvements to the packing logic mean you'll have to do a random 'bzr commit' if you want pack to actually do something.
2) Add a 'bzr pack --force' flag along with (1)
3) Update the pack logic to detect if there was only 1 pack before starting, and check when it is finished if that file is the same as the content it is about to write, in which case it can just cleanly abort, rather than failing.
If we had a way to detect that a pack would result in the same information without actually performing that information, then I wouldn't think to do (3), but since we don't otherwise know if the pack is already optimal... (bzr branch from a different source format creates a single pack file that is *far* from optimal, bzr reconcile, bzr upgrade can all have the same characteristics.)