Comment 3 for bug 242510

So, I just came up with a way to reproduce it. It is a logic bug in the autopacking logic.

bzr init creator
bzr init target
cd creator

for j in 1 55 24 30; do
  for i in `seq $j`; do
    bzr commit -m "$i, $j" --unchanged
  done
  bzr push ../target
done

The problem is thus...

When we get to the final push, we have pack files of size, 55, 30, 24, and 1. And a total of 110 revisions. Which means that the autopacking logic is going to try to push the existing packs together to get a pack of size 100, and one of size 10.

What happens is that it pushes together 55+30+24 = 109 (it is okay with a single-pack worth of overflow). It then tries to combine the "size 1" pack into a pack of size 10. However, there is nothing else for it to combine with, so it just goes ahead and creates a new pack that has exactly the same content.

And thus the target pack name already exists, and everything aborts.

There are a few different ways to handle this, Robert mentioned one about making the packer try harder. We could also detect that we are not changing anything and just not try to repack that object.