Pack already exists when pushing/autopacking

Just hit this again with the LH branch.
Only after running "bzr pack" on the LP branch did I get it back to normal.

Bumping the importance to high.

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.

On Thu, 2008-09-18 at 22:58 +0000, John A Meinel wrote:
>
> 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.

Specifically, I was suggesting that just making a single 110 rev pack is
better - its less work and round trips. That would avoid this.

Also, checking that if we're autopacking with a single pack input, do
nothing, might be a good guard (though be sure not to prevent reconcile
from reconciling a fully packed repository).

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

I have two fixes for this committed in the associate branch. Should make it into 1.8, we'll just see what version "wins out" for the final.

There may be some dupes of this...

Probable cause of OOPS-1000SMPU01 and OOPS-1000SMPM15

Fixed with the updated bzr on Launchpad.