Comment 2 for bug 522296

So I have more results.
On my machine with 12GB RAM 4-core Linux I have two identical 1.14 shared repositories ("identical" as in "copied with cp -a"), I did "check -v" on one copy with bzr.dev, and on another copy with bzr 1.15.1.
* 1.15.1:
- "checking revisions" (87000 of them): took 24 hours
- "checking text storage: calculating text parents" (418000 of them): took 24 hours
- during those two phases, RAM usage was <6%
- then a few hours were spent in checking branches, RAM went to 50%
- the command terminated normally, taking in total 51 hours.
* bzr.dev:
- I killed it, out of patience, after 117 hours
- RAM usage was consistently 50% over all this time
- I cannot tell what the progress bar was saying, because I had redirected stdout to a file, and this makes the progress bar invisible.
* Note that the check with bzr.dev had been started 66 hours before the check with 1.15.1, so it's not a problem of parallel operations loading the machine. And there were no other significant operations on the machine for the whole time.

This seems to surely be a bug introduced between 1.15.1 and bzr.dev :-)
I suspect that you could reproduce this problem by creating a shared repo in 1.14 format, putting into it this branch:
https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-codebase-bugfixing
and then running "bzr check -v". The above branch has the bulk of revisions of my shared repository.