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.
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?
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 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).
Likewise, Docs pops up a menu of documentation I commonly use …
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">
<separator/>
<folder title="QBzr Development">
<toolset name="lp-devel" project="qbzr" />
</folder>
</folder>
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!
Bazaar developers' blog 