[I drafted this post a couple of weeks ago, so there is some later news. It’s still useful so I’ll post it anyhow, with more to come later — mbp]
The short story: brisbane-core has some good size and speed numbers; it’s now merged in to bzr 1.14rc1, so we can get wider testing across Launchpad and from users.
We hope soon to have an “edge” Launchpad code server, which would be working on live data but running release-candidate bzr code for better testing.
As fairly typical numbers for python3.0: fastimport time (similar to repeated commits) is down from 168m to 51m and the repository size is down from 160M to 77.4M. For MySQL the numbers are better, 501MB down to 170MB (nearly 3x). ‘log -v’ which was a particular point for emacs is now about 20x faster than in the 1.9 format.
We don’t have to do much new development as such but we do have to do some more risk reduction, in checking for performance or functionality problems, and some further review before it merges. This testing and tuning will continue after it lands. There are still some operations that are known to be slower than in current formats, such as branching the whole repository, but they should be fairly shallow and are being worked on. (To be clear, they’re only cases where the new format is not as good as it will be, not regressions on current formats.) It makes sense to continue working on these in parallel with letting Launchpad and other people integrate it.
The largest question mark is over how smooth we can make upgrading of stacked branches on Launchpad. This is important but probably something that we should tackle during the beta period, when other things are tied down. We will have a reasonable answer, the question is just how automatic will it be and where will it be done.
Aaron is also now working on nested trees since the sprint and that seems to be going well, with the -subtree variant now obsolete. We’re aiming to do this for 2.0 too but won’t block finishing brisbane-core on it.