'bzr pack' of an already packed dev6 or 2a repo fails with Pack exists

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Albisetti wrote:
> Public bug reported:
>
> When trying to run "bzr pack" on a recently upgraded branch, I get the
> following error with 1.15 (both reconcile and check seem to be fine):
This is perhaps the same thing that happens if you run "bzr pack" a
couple of times in a row on any dev6 repo.

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkokHHUACgkQDLQl4QYPZuWf/wP+KeqpscWw8lArkLXBRUhcDAXr
C1aUEOBNBl3C+oxhGrirjNojKuWs4aDk9dBA6iK6Nc+vLC7m+RGrCr/gP1k2cMA/
b997cLU2rA54+2klAfULSEWhP+lYqxyKFJshKoKJsZkGzSLAJxtb7d9Bq3cc8Exc
sR3njua9tyzGYQ/DDdM=
=AUeW
-----END PGP SIGNATURE-----

Basically, 'bzr pack' is now trying to re-pack the repository, and it gets exactly the same content. When it goes to insert this new pack, it doesn't do any sanity checking to see if it already exists, and obviously fails with a bad error.

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.)

The sort order & C-or-python compressor are both needed to know whether
recompressing will result in the same output.

I think making recompressing when there is already 1 pack require a flag
is probably best, because its usually not the right thing to do, and it
will be a timewaster for most people.

-Rob

I just got this too while testing repacking my 2a launchpad repository.

+1 for a no-op if already only one pack.

I've noticed that `bzr pack` in 2a branch/repo no more is no-op operation when there is only one pack file present. I can run `bzr pack` many times in already packed branch and every time it starts again.

Also on subsequent repack of packed repo `bzr pack` blows with error:

C:\Temp\qbzr-bbc\trunk-2a>bzr pack

C:\Temp\qbzr-bbc\trunk-2a>bzr pack
bzr: ERROR: File exists: u'C:/Temp/qbzr-bbc/trunk-2a/.bzr/repository/upload/hz5plvk08aqz10duwmal.autopack': [Error 183] Cannot create a file when that file already exists

C:\Temp\qbzr-bbc\trunk-2a>bzr pack
bzr: ERROR: File exists: u'C:/Temp/qbzr-bbc/trunk-2a/.bzr/repository/upload/gmki2l0f66pj13kol7j7.autopack': [Error 183] Cannot create a file when that file already exists

I vote for make `bzr pack` no-op again when there is only one pack file, and maybe provide --force option to force re-packing anyway if new and improved packed algorithms will become available for --2a and future formats.

Setting this to high, since a lot of people seem to be hitting this and being confused by this.

I half-accidentally fixed this in my inventory-delta branch :)