1
*************************
2
What's New in Bazaar 2.3?
3
*************************
5
Bazaar 2.3 is still under development, and will be released in February
6
2011. This document accumulates a high level summary of what's changed.
8
:doc:`../release-notes/index` for a full list.
10
Users are encouraged to upgrade from the other stable series. This
11
document outlines the improvements in Bazaar 2.3 vs Bazaar 2.2. As well as
12
summarizing improvements made to the core product, it highlights
13
enhancements within the broader Bazaar world of potential interest to
16
Bazaar 2.3.0 is fully compatible both locally and on the network with 2.0
17
2.1, and 2.2, and can read and write repositories generated by all
23
* Committing a new revision in a stacked branch is now supported, as long as
24
you are using the current repository format (2a). It will preserve the
25
stacking invariants, etc, so that fetching after commit is guaranteed to
26
work. (John Arbash Meinel, #375013)
28
* Support for some old development formats have been removed:
29
``development-rich-root``, ``development6-rich-root``, and
30
``development7-rich-root``. These formats were always labelled experimental
31
and not used unless the user specifically asked for them. If you have
32
repositories using these old formats you should upgrade them to ``2a`` using
33
Bazaar 2.2. (Andrew Bennetts)
35
* The default ``ignore`` file created by Bazaar will contain ``__pycache__``,
36
which is the name of the directory that will be used by Python to store
38
(Andrea Corbellini, #626687)
40
* The default sort order for the ``bzr tags`` command now uses a natural sort
41
where numeric substrings are sorted numerically. The previous default was
42
"asciibetical" where tags were sorted by the characters they contained. To
43
get the old behavior, one can use ``bzr tags --sort=alpha``.
44
(Neil Martinsen-Burrell, #640760)
46
* On platforms other than Windows and Mac OS X, Bazaar will use configuration
47
files that live in $XDG_CONFIG_HOME/bazaar if that directory exists. This
48
allows interested individuals to conform to the XDG Base Directory
49
specification. The plugin location has not changed and is still
50
~/.bazaar/plugins. To use a different directory for plugins, use the
51
environment variable BZR_PLUGIN_PATH. (Neil Martinsen-Burrell, #195397)
53
* ``bzr upgrade`` now operates recursively when run on a shared
54
repository, automatically upgrading the branches within it, and has
55
grown additional options for showing what it will do and cleaning up
56
after itself. (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
61
* The ``lp:`` prefix will now use your known username (from
62
``bzr launchpad-login``) to expand ``~`` to your username. For example:
63
``bzr launchpad-login user && bzr push lp:~/project/branch`` will now
64
push to ``lp:~user/project/branch``. (John Arbash Meinel)
66
* Launchpad has announced that the ``edge.launchpad.net`` instance is
67
deprecated and may be shut down in the future
68
<http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
69
been updated in this release to talk to the main (``launchpad.net``) servers,
70
rather than the ``edge`` ones.
72
Performance improvements
73
************************
75
* ``bzr revert`` and ``bzr status`` are up to 15% faster on large trees
76
with many changes by not repeatedly building a list of all file-ids.
79
* ``bzr send`` uses less memory.
80
(John Arbash Meinel, #614576)
82
* Fetches involving stacked branches and branches with tags now do slightly less
83
I/O, and so does branching from an existing branch. This also improves the
84
network performance of these operations. (Andrew Bennetts)
86
* Inventory entries now consume less memory (on 32-bit Ubuntu file entries
87
have dropped from 68 bytes to 40, and directory entries from 120 bytes
88
to 48). This affects most operations, and depending on the size of the
89
tree may substantially improve the speed of operations like ``bzr
90
commit``. (Andrew Bennetts)
92
* Lower memory consumption when reading many chk index pages. Helpful for
93
things like ``bzr co`` or ``bzr ls -R`` on large trees.
96
* When building new working trees, default to reading from the repository
97
rather than the source tree unless explicitly requested. (via
98
``--files-from`` and ``--hardlink`` for ``bzr branch`` and
99
``bzr checkout``. Generally, 2a format repositories extract
100
content faster than seeking and reading content from another tree,
101
especially in cold-cache situations. (John Arbash Meinel, #607298)
103
New revision specifiers
104
***********************
106
* The ``mainline`` revision specifier has been added. It takes another revision
107
spec as its input, and selects the revision which merged that revision into
110
For example, ``bzr log -vp -r mainline:1.2.3`` will show the log of the
111
revision that merged revision 1.2.3 into mainline, along with its status
112
output and diff. (Aaron Bentley)
114
* The ``annotate`` revision specifier has been added. It takes a path and a
115
line as its input (in the form ``path:line``), and selects the revision which
116
introduced that line of that file.
118
For example: ``bzr log -vp -r annotate:bzrlib/transform.py:500`` will select
119
the revision that introduced line 500 of transform.py, and display its log,
120
status output and diff.
122
It can be combined with ``mainline`` to select the revision that landed this
123
line into trunk, like so:
124
``bzr log -vp -r mainline:annotate:bzrlib/transform.py:500``
127
Testing/Bug reporting
128
*********************
130
* Shell-like scripts can now be run directly from the command line without
131
writing a python test. This should help users adding reproducing recipes
132
to bug reports. (Vincent Ladeuil)
135
Improved conflict handling
136
**************************
138
* ``pull``, ``merge`` or ``switch`` can lead to conflicts when deleting a
139
versioned directory contains unversioned files. The cause of the conflict
140
is that deleting the directory will orphan the unversioned files so the
141
user needs to instruct ``bzr`` what do to do about these orpahns. This is
142
controlled by setting the ``bzr.transform.orphan_policy`` configuration
143
variable with a value of ``move``. In this case the unversioned files are
144
moved to a ``bzr-orphans`` directory at the root of the working tree. The
145
default behaviour is specified (if needed) by setting the variable to
146
``conflict``. (Vincent Ladeuil, #323111)
148
* ``bzr resolve --take-this`` and ``bzr resolve --take-other`` can now be
149
used for text conflicts. This will ignore the differences that were merged
150
cleanly and replace the file with its content in the current branch
151
(``--take-this``) or with its content in the merged branch
152
(``--take-other``). (Vincent Ladeuil, #638451)
154
* ``bzr resolve`` now provides more feedback about the conflicts just
155
resolved and the remaining ones. (Vincent Ladeuil)
160
* A beta version of the documentation is now available in GNU TexInfo
161
format, used by emacs and the standalone ``info`` reader.
162
(Vincent Ladeuil, #219334)
167
``bzr`` can be configured via environment variables, command-line options
168
and configurations files. We've started working on unifying this and give
169
access to more options. The first step is a new ``bzr config`` command that
170
can be used to display the active configuration options in the current
171
working tree or branch as well as the ability to set or remove an
172
option. Scripts can also use it to get only the value for a given option.
174
Expected releases for the 2.3 series
175
************************************
177
The 2.3 series has entered the beta phase and 2.3.0 should be released soon
178
enough to be included into Natty Narwhal.
180
As a rough estimate, consider that 2.3.0 will be released in February
181
2011 and be supported until August 2012. Additional releases will be
182
made if critical bugs are encountered
188
For more detailed information on the changes made, see the
189
the :doc:`../release-notes/index` for:
191
* the interim bzr `milestones <https://launchpad.net/bzr/2.3>`_
192
* the plugins you use.
194
For a summary of changes made in earlier releases, see:
196
* :doc:`whats-new-in-2.1`
197
* :doc:`whats-new-in-2.2`