I’ve worked with Robert Collins for the last 5 years or so at Canonical, and it’s been a real pleasure. Now Robert’s moving on to a great new rôle at Canonical, as technical architect of Launchpad. I can’t think of a better job for him, or a better person for the role, and it’s already paying off through Launchpad becoming faster (shorter page timeouts and hitting them less often) and I think more fun to work on. (See also his stump speech.)
Now we’re looking for a very good software engineer to join the Bazaar team at Canonical, working both on the core tool itself and on how it’s used by Ubuntu developers. We would love to get more applications from people with packaging or distro experience. I want to work with someone who’s very driven, who’ll reach out to their users and not wait to be told what to do, someone who knows the whole environment we work in, and someone who cares about doing good things.
At the moment bzr treats deletion of a directory containing unversioned files (either ignored or unknown) as a conflict.
This is a bit annoying because often the unversioned files are generated trash, like .pyc files from Python. However in some cases people do have “precious” files that are ignored but shouldn’t be just deleted.
Vincent has a merge proposal up that will instead move the files into a bzr-orphans directory in the root of the tree.
What would you like to have happen? My feeling is that there should be a configuration option to choose the policy, and we should perhaps eventually distinguish “junk” (safe to delete) from “precious”, as Baz and GNU Arch did.
We’re going to release bzr 2.2b4 this week, which will be the final beta for the bzr 2.2 series and the start of the 2.2 release branch. From this point on the 2.2 will be an API freeze, so that any plugins that are updated to work with 2.2b4 will also work with 2.2.0 and future bugfix updates. We plan to do 2.2.0 at the end of July.
2.2 brings a bunch of performance, correctness and usability improvements.
Review of Launchpad and Bazaar on ArsTechnica by the lead developer of gwibber.
- Likes the way the bzr client feeds into the web ui, by setting bug links etc
- Easy automatic imports from cvs, svn, git and hg, either for a one-shot cutover or continuing tracking
- More powerful bug tracking than github
- Loggerhead feels slow and poorly integrated with Launchpad, but qbzr is brilliant
- Merge proposals good for tracking contributions
One of the primary reasons why Bazaar exists is that Canonical wants to make it as easy as possible for more people to contribute to FOSS (Free and Open Source Software) projects. After many years of development, the pieces of the puzzle are really falling into place nicely. See the tutorial I put together last week to see just how easy it can be.
Are you a Bazaar fan and need some help explaining to others why Bazaar is cool? I published a document last week called Why switch to Bazaar? that may help. I’ve tried hard to present the big picture together with some concrete examples, explaining what we stand for and what that means to users, teams and communities in reality. Furthermore, if you tried Bazaar 1.x but found it too slow or inefficient, I’m sure you’ll find the Bazaar 2.0 benchmarks included in the document great news.
I hope you find the document interesting and food for thought. If there are any mistakes or you’ll like to translate the document to another language, please let me know.
[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.
qbzr is one of the graphical interfaces to bzr. It’s the default interface on Windows, and also popular on Linux.
garyvdm added a nice new revision selector control to qbzr: