Comment 49 for bug 405251

None of the tools to manipulate a repository (rebase, fast-export, fast-import) work at all, so I did the following:
1. Create a standalone branch to the last version that was OK (1292). This causes a .bzr of 220MB.
2. Now pull the higher revisions one by one using pull -r [next] and size the .bzr directory.
This clearly exhibits the problematic pulls at certain revisions. I will add the console history for this action; I stopped testing at revision 1322 because the trend is clear.
Highlights from the log:
pull 1307: repository grows from 234MB to 249MB for a two file fix without any merge at all; the diff for this is 1764 bytes.
pull 1311: from 249 to 275MB for a change containing two small files again
pull 1318: from 276 to 398MB; this actually added 17MB of .jar files in a single commit. The pull took a long time.
pull 1320: from 398 to 414MB, pull took a long time
pull 1322: from 415 to 585MB; the pull took very long and was busy for a long time with copying "content texts". As can be seen from the console log the actual size of the workspace itself grew with 1MB for this pull while the repository grew 170MB..
I stopped at pull 1323 ending in a repository size of 586M and total dir size (repo+working tree) of 850M.

At this point I did a "bzr pack" on this repository. This helpfully created a .bzr repo of 791MB; I assumed I could remove the "obsolete_packs" (395MB) directory; this resulted in a repository of 397MB. Still very big when I see what has changed.