What’s New in Bazaar 2.3?¶
Bazaar 2.3 has been released on the 3rd of February 2011 and marks the start of another long-term-stable series. From here, we will only make bugfix releases on the 2.3 series (2.3.1, etc), while 2.4 will become our new development series. The 2.1 and 2.2 series will also continue to get bugfixes. (Currently 2.0 is planned to be EOLed circa September 2011.)
This document accumulates a high level summary of what’s changed. See the Breezy Release Notes for a full list.
Users are encouraged to upgrade from the other stable series. This document outlines the improvements in Bazaar 2.3 vs Bazaar 2.2. As well as summarizing improvements made to the core product, it highlights enhancements within the broader Bazaar world of potential interest to those upgrading.
Bazaar 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5 versions that weren’t included in 2.3.0 and fixes some bugs on its own.
Bazaar 2.3.2 is a bugfix release that was never released.
Bazaar 2.3.3 is a bugfix release including the fixes in 2.3.2 and fixing the test helpers deprecated by python-2.7.
Bazaar 2.3.4 is a bugfix release.
See the Breezy Release Notes for details.
Bazaar 2.3 is fully compatible both locally and on the network with 2.0, 2.1, and 2.2. It can read and write repositories generated by all previous versions.
Committing a new revision in a stacked branch is now supported, as long as you are using the current repository format (2a). It will preserve the stacking invariants, etc, so that fetching after commit is guaranteed to work. (John Arbash Meinel, #375013)
Support for some old development formats have been removed:
development7-rich-root. These formats were always labelled experimental and not used unless the user specifically asked for them. If you have repositories using these old formats you should upgrade them to
2ausing Bazaar 2.2. (Andrew Bennetts)
ignorefile created by Bazaar will contain
__pycache__, which is the name of the directory that will be used by Python to store bytecode files. (Andrea Corbellini, #626687)
The default sort order for the
bzr tagscommand now uses a natural sort where numeric substrings are sorted numerically. The previous default was “asciibetical” where tags were sorted by the characters they contained. To get the old behavior, one can use
bzr tags --sort=alpha. (Neil Martinsen-Burrell, #640760)
On platforms other than Windows and Mac OS X, Bazaar will use configuration files that live in $XDG_CONFIG_HOME/bazaar if that directory exists. This allows interested individuals to conform to the XDG Base Directory specification. The plugin location has not changed and is still ~/.bazaar/plugins. To use a different directory for plugins, use the environment variable BZR_PLUGIN_PATH. (Neil Martinsen-Burrell, #195397)
bzr upgradenow operates recursively when run on a shared repository, automatically upgrading the branches within it, and has grown additional options for showing what it will do and cleaning up after itself. (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
lp:prefix will now use your known username (from
bzr launchpad-login) to expand
~to your username. For example:
bzr launchpad-login user && bzr push lp:~/project/branchwill now push to
lp:~user/project/branch. (John Arbash Meinel)
Launchpad has announced that the
edge.launchpad.netinstance is deprecated and may be shut down in the future <http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore been updated in this release to talk to the main (
launchpad.net) servers, rather than the
bzr statusare up to 15% faster on large trees with many changes by not repeatedly building a list of all file-ids. (Andrew Bennetts)
bzr senduses less memory. (John Arbash Meinel, #614576)
Fetches involving stacked branches and branches with tags now do slightly less I/O, and so does branching from an existing branch. This also improves the network performance of these operations. (Andrew Bennetts)
Inventory entries now consume less memory (on 32-bit Ubuntu file entries have dropped from 68 bytes to 40, and directory entries from 120 bytes to 48). This affects most operations, and depending on the size of the tree may substantially improve the speed of operations like
bzr commit. (Andrew Bennetts)
Lower memory consumption when reading many chk index pages. Helpful for things like
bzr ls -Ron large trees. (John Arbash Meinel)
When building new working trees, default to reading from the repository rather than the source tree unless explicitly requested. (via
bzr checkout. Generally, 2a format repositories extract content faster than seeking and reading content from another tree, especially in cold-cache situations. (John Arbash Meinel, #607298)
New revision specifiers¶
mainlinerevision specifier has been added. It takes another revision spec as its input, and selects the revision which merged that revision into the mainline.
bzr log -vp -r mainline:1.2.3will show the log of the revision that merged revision 1.2.3 into mainline, along with its status output and diff. (Aaron Bentley)
annotaterevision specifier has been added. It takes a path and a line as its input (in the form
path:line), and selects the revision which introduced that line of that file.
bzr log -vp -r annotate:bzrlib/transform.py:500will select the revision that introduced line 500 of transform.py, and display its log, status output and diff.
It can be combined with
mainlineto select the revision that landed this line into trunk, like so:
bzr log -vp -r mainline:annotate:bzrlib/transform.py:500(Aaron Bentley)
Shell-like scripts can now be run directly from the command line without writing a python test. This should help users adding reproducing recipes to bug reports. (Vincent Ladeuil)
Improved conflict handling¶
switchcan lead to conflicts when deleting a versioned directory contains unversioned files. The cause of the conflict is that deleting the directory will orphan the unversioned files so the user needs to instruct
bzrwhat do to do about these orpahns. This is controlled by setting the
bzr.transform.orphan_policyconfiguration variable with a value of
move. In this case the unversioned files are moved to a
bzr-orphansdirectory at the root of the working tree. The default behaviour is specified (if needed) by setting the variable to
conflict. (Vincent Ladeuil, #323111)
bzr resolve --take-thisand
bzr resolve --take-othercan now be used for text conflicts. This will ignore the differences that were merged cleanly and replace the file with its content in the current branch (
--take-this) or with its content in the merged branch (
--take-other). (Vincent Ladeuil, #638451)
bzr resolvenow provides more feedback about the conflicts just resolved and the remaining ones. (Vincent Ladeuil)
A beta version of the documentation is now available in GNU TexInfo format, used by emacs and the standalone
inforeader. (Vincent Ladeuil, #219334)
bzr can be configured via environment variables, command-line options
and configurations files. We’ve started working on unifying this and give
access to more options. The first step is a new
bzr config command that
can be used to display the active configuration options in the current
working tree or branch as well as the ability to set or remove an
option. Scripts can also use it to get only the value for a given option.