Comment 1 for bug 326369

Inspired by similar topic in the bug tracker, I delved a bit deeper and found:

sehe@intrepid:~/UWV/work$ du -shc .bzr/repository/*
4.0K .bzr/repository/format
988K .bzr/repository/indices
0 .bzr/repository/lock
0 .bzr/repository/no-working-trees
26M .bzr/repository/obsolete_packs
4.0K .bzr/repository/pack-names
25M .bzr/repository/packs
0 .bzr/repository/shared-storage
0 .bzr/repository/upload
52M total

So it turns out, in fact, I was right: my repository was doubled. In fact, it seems like it has been a very fancy way to say

cp -a .bzr/repository/packs .bzr/repository/obsolete_packs

Ok, perhaps (or not, because that info doesn't follow from these figures) at most 1Mb was shaved of the size of the packs subdir. But the benefit is more than thwarted by the fact that I'm now the proud owner of 26Mb in obsolete packs. I'm not sure why these are kept (perhaps a backup measure?) but I'm pretty sure there is no mention of it in the docs for the pack command, and it seems to grossly violate the principle of least surprise.

I'd guess I should run 'bzr pack' before rsync-ing my repository. It turns out, this is exactly what I shouldn't do, because it will (can?) double the volume of the transfer.

- is there any mention of this behaviour (+reason?) in the docs for 'bzr pack'
- is there a specific command to get rid of the bloat in obsolete-packs (clean-tree doesn't, and pack doesn't)
- shouldn't the user be warned that backups are taken and not going to be freed automatically?

Regards,
Seth