The GNU GRUB project is currently evaluating Bazaar, starting with a bzr-svn conversion of the existing Subversion repository. Since the maintainer driving this is a Debian developer who, all things being equal, would like the branch to be usable on Debian stable, he's been using the versions of bzr and bzr-svn in Lenny (1.5 and 0.4.10 respectively). I've noted that these are very old in Bazaar terms, and he's receptive to upgrading if we can show that an upgrade will fix some of the problems being encountered.
Following the initial bzr-svn import, Robert made a number of commits to the Subversion repository using a bzr client, relying on roundtripping of revisions. At some point, this resulted in corrupted revisions. 'bzr check' (with bzr 2.0.0) dies as follows:
bzr: ERROR: bzrlib.errors.SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0xacacc6c> corrupt: sha-1 of reconstructed text does not match expected sha-1. key ('<email address hidden>',) expected sha 5106634edd37d3b7403caa4c9c2298520f1f5fdc actual sha 54329caf5b6e40f5526416dfbe9b159ae13a70a5
I've attached part of the corrupted repository and branch, pulled from http://bzr.sv.gnu.org/r/grub/trunk; I'm attaching it here because we may zap that repository and start over in order to recover from this. Everything up to revision 1777 checked fine, while revision 1778 failed.
I've also attached the crash file.
The problem here is that the text revisions haven't been recorded properly in all cases. Since the text revisions are recorded explicitly in the inventory text this causes sha-1 differences of the inventories, and that causes "bzr check" to blow up like it does. This is a problem with the pre-2a bzr formats since they store the inventory as one big XML blob.
Upgrading the bzr repository to 2a while ignoring this issue fixes the problem. I've pushed a fixed 2a branch to lp:~jelmer/grub/fixed