Martin Pool

bzr 2.2 even faster

A nice mail from Martitza this morning:

Hi.  Some of you may recall that I’ve provided measurements of some slow operations in both bzr itself and bzr-explorer based on bzrlib 2.1 and earlier.  I don’t recall doing any testing on bzr 2.2.0 specifically, but now that I’m on bzr 2.2.1 bzr (and bzr-explorer) are noticeably faster and even more pleasant to use now.   So far it seems that each of the add/commit/status operations on sets of 10K+ files (500MB+ branches) takes no more than two or three minutes each.  This is twice as fast as some of my previous measurements on the same or smaller branches.  Also, memory consumption is much reduced, which I suspect helps a lot.  I even have one of these large repos hosted on an old 512MB Pentium 3 machine with no problem today.  This is wonderful!  I hesitate to name the people I know made this possible, because I do not want to leave out the many more people whose contributions I don’t know.  Please accept my thanks to the whole team.

Martin Pool

want to work on Bazaar?

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.

Martin Pool

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.

Martin Pool

farewell, Ian

I am grieved to say that my friend and colleague Ian Clatworthy died last night, after a long and horrible struggle with cancer. He and his wife Geri celebrated their 19th wedding anniversary yesterday before he passed away peacefully in his sleep, at home, with his family.

I’ve known Ian for eleven years and he has worked at Canonical since 2007. He made large contributions to Bazaar, including launching and driving the bzr-explorer project. Even though he had many technical and business achievements, the most remarkable and inspiring thing was what a thoroughly nice man he was. He was determined to change the world for the better, both in software and in how people relate to each other, and he accomplished both. He will be missed, and remembered.

– Martin

[edit: add picture]

Ian Clatworthy 1966-2010

Martin Pool

bugzilla-bzr integration

Max Kanat-Alexander’s new bugzilla-vcs extension (alpha) supports bzr, svn, hg, git, and cvs. Currently it supports linking bugs and commits, and displaying information about about commits in Bugzilla on the show_bug page.

Martin Pool

John Barlow’s new Bazaar TFS plugin adds support for Microsoft Team Foundation Server repositories, allowing one to use Bazaar to branch, merge, and commit code to remote TFS repositories.

Martin Pool

bzr 2.2 releasing in July

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.

Martin Pool

nice fast grep

Parth announced bzr-grep 0.2.0.  Amongst other things there are performance enhancements such that Eli says:

Thanks, this looks great. I just tried it on Windows XP searching for a fixed string in the Emacs repository — took 28 seconds with a cold cache and only 7.5 with a warm cache, which is impressive.

By contrast, “grep -F -R” (with suitable –exclude patterns, to prevent it from searching binary files and inside .bzr) took about 12.5 seconds with a warm cache.

Martin Pool

Every six months, the Bazaar team makes a major release, like the recent 2.1.0. This starts a stable series of bugfix-only updates that lasts for at least six months: no format or network changes, minimum chance of regression, and no disruption to plugins or other API clients. The idea is that people can install a major release, perhaps standardize their team on it, and then get fixes but no disruptive upgrades.

We’ve been doing this for just over a year now, and it’s going very well: the point releases are getting into the update channel for Ubuntu, Fedora, and other distros.

Now we have two stable series currently supported, with 2.0.5 and 2.1.1 just recently released, and 2.2b1 coming out at the end of this week.

We’re wondering: how long should we maintain these series, and how often should we do releases from them? On the code side, maintaining multiple branches in Bazaar is pretty easy, but making installers for all platforms, uploading and announcing them does take some work for every release we do.

At the moment I’m leaning towards supporting each of them for at least a year, but perhaps pushing out the interval between bugfix updates on stable branches: perhaps every two months, unless a critical bug is fixed.

What do you think? Are you using, or thinking of using a stable-series release of Bazaar? Would upgrading to a new stable branch every year be realistic? Are you getting bugfixes at about the right rate?

Ian Clatworthy

Bazaar Explorer's Killer Feature

Bazaar Explorer 1.0.0 hits the streets yesterday. It’s now well entrenched in my Top 5 applications along with Firefox, Thunderbird and gvim – I truly love using it. Some user docs are coming but in the meantime, here’s a quick look at my favorite feature … project-specific tools.

The first time I opened a repository called “bzr”, Explorer guessed that I was working on the core Bazaar project and asked if I wanted to use the bzr “Hat”. I replied Yes. Now, every time I open a branch in that repository, my toolbox magically gets a Bazaar Development section as shown below.

The Toolbox

The first 3 actions take me to the Open Questions, New Bugs and Active Code Reviews for bzr on Launchpad. That lets me reply to support questions, triage new issues and review merge proposals. Clicking on Servers pops up a menu of bzr-related web sites I visit from time to time, the PQM bot that merges proposed changes to our mainline (if and only if all tests pass) and our Hudson continuous integration server (that runs our regression test suite on lots of  different operating systems).

Servers for bzr

Likewise, Docs pops up a menu of documentation I commonly use …

Docs for bzr

BTW, you don’t need to be using a shared repository for Explorer to propose using a Hat for given location and its subdirectories. Opening a branch or checkout with the right name will work as well. If you don’t want to use a Hat for a location, that’s equally fine. Explorer will remember that fact and not ask you again.

This feature isn’t only for “bzr” development either. Explorer ships with around 20 hats for a variety of popular open source projects on Launchpad including MySQL, Inkscape, Gwibber, Mailman, GNOME Do and Launchpad itself. You can easily create your own as well by simply adding a hats/project-name/tools.xml file under your explorer configuration directory (e.g. ~/.bazaar/explorer). Here’s a sample tools.xml file:

<folder title="Tools">
<folder title="QBzr Development">
<toolset name="lp-devel" project="qbzr" />

It might just be me but I find project-specific tools mega cool: fast access to the places I need to visit, anytime I’m working on a particular project. Explorer is and will remain an easy-to-use GUI application suitable for casual users of version control. My grand vision though is for it to evolve into a collaboration-centric, BYO editor IDE, suitable for hard-code developers like myself to spend most of their day in. Keeping the easy-vs-powerful balance right won’t be easy but I’m confident we can do it. Give it a try and let us know how it works for you!