[MERGE][bug #242510] Don't repack a single entry

John Arbash Meinel john at arbash-meinel.com
Fri Sep 19 16:12:26 BST 2008

Hash: SHA1

This is a fairly simple fix. Basically, when the autopack logic decides how it
wants to lay out the new set of packs, it can decide that it wants to put an
existing pack into a new pack, but not put anything else with it. When it hits
that condition, it ends up creating an identical pack, and the has a name

The patch is fairly straightforward. I'm thinking to put together a different
patch which changes the logic, but that takes a bit more effort, and I'd like
to have a bugfix available.

The existing code says something like:

   Given packs of size 55, 25, 21, 9, (total of 110 revisions). It ends up
   creating packs of size 101, and 9.

The new code just notices that the last pack is a 'no-op' pack, and removes it.

I also audited the logic, to see if there was another way it could fail, and I
didn't really see one. (I was concerned about the bucket resizing logic, but I
can't come up with a way it could fail.)

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: autopack_bug_242510.patch
Type: text/x-diff
Size: 10312 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080919/08db77fd/attachment-0001.bin 

More information about the bazaar mailing list