"missing referenced chk root" while merging gcc into gcc-linaro

jelmer talked with ams about this on IRC: http://irclogs.ubuntu.com/2012/03/14/%23bzr.txt

<jelmer> there is invalid data in one of the two branches caused by an old bzr-svn bug

<jelmer> joey: if you don't care about the actual history of gcc-linaro, then the simplest thing to do would be to take the last revision from lp:gcc that was merged into lp:gcc-linaro, "rsync --delete -avz" over the existing contents from lp:gcc-linaro and commit it in a single commit

<joey> hmm I'd have to talk to michael hope about that. It may be possible for us to start a new series as part of normal ops and then fix it that way

<joey> jelmer: gotcha. If we can't resync because we need history, is there another method we can use?

<jelmer> joey: I think you would have to replay the history and make sure text revisions are recorded consistently with the way they are in lp:gcc

So, it turns out we do already have *a* way of fixing broken repositories like this by replaying all data and recording the text revisions properly. This is fairly well hidden, and can be done by running "bzr reconcile --canonicalize-chks" in the affected repository(s).

Unfortunately this command is quite slow - on my machine it took 4 hours for the gcc repo just to get to rev 100, which is only a tiny fraction of the 115544 revisions in the repository overall.

Seems like 'quite slow' is something of an understatement. Do we want a followup bug for making it less pathological?

> Seems like 'quite slow' is something of an understatement. Do we want a followup bug for making it less pathological?

Yes.

In addition, it looks like 'bzr reconcile --canonicalize-chks' doesn't seem to fix all instances of this problem. Just confirmed this with glyph for the twisted repository.

I'm afraid the current fix isn't usable if it's that slow. Jelmer's numbers suggest the repair would take six months.