The Bazaar Explorer GUI is now available in 11 human languages (and partially translated into a few more) including Algis Kaballa’s recent translation into Lithuanian.

A number of new features have been added to QBzr, related to the management of your working tree. These feature are available from both qbrowse, and qcommit, and are available in the qbzr 0.16 release.

As you can see in the screen shot, we now show conflicts in the status column. Behind the scenes, “Merge conflict” uses extmerge, so that need installed and configured to work. “Mark conflict resolved” does a bzr resolve on the selected file.

“Remove” will unversion, and remove the file. It will prompt you if there are uncommitted changed that will be removed.

Moving and renameing

There are 3 new features that allow you to move or rename a file:

• You can select rename from the context menu, and enter a new name.
• You can move a file by drag it to a new folder.
• If you have renamed or moved a file outside of bzr, you can select the old path (missing), and the new path (unversoined) and chose “Mark as moved/renamed”.
  

Gary van der Merwe, a long-standing bzr and qbzr contributor, is the newest bzr pqm committer.

Neil Martinsen-Burrell just announced MCREPOGEN, a tool to generate random version control histories for Bazaar or anything that can read the fastimport format.

It uses a Markov Chain model where the states are directory trees and various changes to the tree have associated probabilities. The intent is that by giving complete control over the characteristics of the history, performance testing of different aspects of VCS can be improved.

As part of my drive to make it easier for users to switch to Bazaar, I’ve been working with some of our community members on a Bazaar Survival Guide, a manual explaining Bazaar to refugees of other tools in terms they already know. We now have sections for CVS, Subversion, Mercurial, Darcs, Monotone and ClearCase users. Hopefully, we’ll have sections soon for other popular tools.

A huge thanks to everyone who has helped with this! I think it is coming along nicely.

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’ve been looking into our user base in recent days. The results are pretty pleasing: solid numbers of adopters on both Ubuntu and Windows. All up, I estimate we have 80-100k users by the time other operating systems are taken into account.

See http://bazaar-vcs.org/BzrPopularity.

Ian posted some numbers on bzr repository size vs hg and git. The short story: bzr’s 2.0 format is better than hg on every project tested, and within epsilon for git.

Bazaar uses compiled extensions, written in Pyrex or C, for some key operations. (These typically compile to names like _chk_map_pyx.so or dll.) These extensions are optional, because we can fall back to a pure-Python version, but they make an order-of-magnitude difference to the speed of some operations.

Most users never need to know about them because the extensions are built and included in the binary package they install for their platform.

Starting after bzr 2.0, Bazaar gives you a warning if it can’t load the extensions. We want to make sure that people aren’t unintentionally getting bad performance, while still letting them run pure Python if they wish.

We’re thinking about cases like these: people running from source without compiling, or a problem in bzr, packaging, or the OS python infrastructure (like Ubuntu bug 392355) that means the extensions never get loaded. We want at least some kind of warning light, rather than for things to just be mysteriously slow.

A few people are now hitting this warning. The typical cause seems to be that they’re running bzr.dev tip and haven’t run make in that directory after updating. We’ll change the warning (bug 430529) to make it more clear that’s what you have to do. If you want to just silence it, run (on Unix)

echo ignore_missing_extensions=True >> ~/.bazaar/bazaar.conf

To see what changes a remote branch would make if you merged it into yours, try something like this:

bzr merge --preview lp:~spiv/bzr/insert-stream-check-chks-part-2|tee /tmp/spiv.diff