2
2
What's New in Bazaar 2.3?
3
3
*************************
5
Bazaar 2.3 has been released on the 3rd of February 2011 and marks the start
6
of another long-term-stable series. From here, we will only make bugfix
7
releases on the 2.3 series (2.3.1, etc), while 2.4 will become our new
8
development series. The 2.1 and 2.2 series will also continue to get
9
bugfixes. (Currently 2.0 is planned to be EOLed circa September 2011.)
11
This document accumulates a high level summary of what's changed.
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.
13
8
:doc:`../release-notes/index` for a full list.
15
Users are encouraged to upgrade from the other stable series. This document
16
outlines the improvements in Bazaar 2.3 vs Bazaar 2.2. As well as summarizing
17
improvements made to the core product, it highlights enhancements within the
18
broader Bazaar world of potential interest to those upgrading.
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
20
Bazaar 2.3.0 is fully compatible both locally and on the network with 2.0 2.1,
21
and 2.2, and can read and write repositories generated by all previous
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
27
* Committing a new revision in a stacked branch is now supported, as long as
28
you are using the current repository format (2a). It will preserve the
29
stacking invariants, etc, so that fetching after commit is guaranteed to
30
work. (John Arbash Meinel, #375013)
32
* Support for some old development formats have been removed:
33
``development-rich-root``, ``development6-rich-root``, and
34
``development7-rich-root``. These formats were always labelled experimental
35
and not used unless the user specifically asked for them. If you have
36
repositories using these old formats you should upgrade them to ``2a`` using
37
Bazaar 2.2. (Andrew Bennetts)
39
23
* The default ``ignore`` file created by Bazaar will contain ``__pycache__``,
40
24
which is the name of the directory that will be used by Python to store
47
31
get the old behavior, one can use ``bzr tags --sort=alpha``.
48
32
(Neil Martinsen-Burrell, #640760)
50
* On platforms other than Windows and Mac OS X, Bazaar will use configuration
51
files that live in $XDG_CONFIG_HOME/bazaar if that directory exists. This
52
allows interested individuals to conform to the XDG Base Directory
53
specification. The plugin location has not changed and is still
54
~/.bazaar/plugins. To use a different directory for plugins, use the
55
environment variable BZR_PLUGIN_PATH. (Neil Martinsen-Burrell, #195397)
57
* ``bzr upgrade`` now operates recursively when run on a shared
58
repository, automatically upgrading the branches within it, and has
59
grown additional options for showing what it will do and cleaning up
60
after itself. (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
62
34
Launchpad integration
63
35
*********************
67
39
``bzr launchpad-login user && bzr push lp:~/project/branch`` will now
68
40
push to ``lp:~user/project/branch``. (John Arbash Meinel)
70
* Launchpad has announced that the ``edge.launchpad.net`` instance is
71
deprecated and may be shut down in the future
72
<http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
73
been updated in this release to talk to the main (``launchpad.net``) servers,
74
rather than the ``edge`` ones.
76
42
Performance improvements
77
43
************************
83
49
* ``bzr send`` uses less memory.
84
50
(John Arbash Meinel, #614576)
86
* Fetches involving stacked branches and branches with tags now do slightly less
87
I/O, and so does branching from an existing branch. This also improves the
88
network performance of these operations. (Andrew Bennetts)
90
52
* Inventory entries now consume less memory (on 32-bit Ubuntu file entries
91
53
have dropped from 68 bytes to 40, and directory entries from 120 bytes
92
54
to 48). This affects most operations, and depending on the size of the
128
90
``bzr log -vp -r mainline:annotate:bzrlib/transform.py:500``
131
Testing/Bug reporting
132
*********************
134
* Shell-like scripts can now be run directly from the command line without
135
writing a python test. This should help users adding reproducing recipes
136
to bug reports. (Vincent Ladeuil)
139
Improved conflict handling
140
**************************
142
* ``pull``, ``merge`` or ``switch`` can lead to conflicts when deleting a
143
versioned directory contains unversioned files. The cause of the conflict
144
is that deleting the directory will orphan the unversioned files so the
145
user needs to instruct ``bzr`` what do to do about these orpahns. This is
146
controlled by setting the ``bzr.transform.orphan_policy`` configuration
147
variable with a value of ``move``. In this case the unversioned files are
148
moved to a ``bzr-orphans`` directory at the root of the working tree. The
149
default behaviour is specified (if needed) by setting the variable to
150
``conflict``. (Vincent Ladeuil, #323111)
152
* ``bzr resolve --take-this`` and ``bzr resolve --take-other`` can now be
153
used for text conflicts. This will ignore the differences that were merged
154
cleanly and replace the file with its content in the current branch
155
(``--take-this``) or with its content in the merged branch
156
(``--take-other``). (Vincent Ladeuil, #638451)
158
* ``bzr resolve`` now provides more feedback about the conflicts just
159
resolved and the remaining ones. (Vincent Ladeuil)
165
97
format, used by emacs and the standalone ``info`` reader.
166
98
(Vincent Ladeuil, #219334)
171
``bzr`` can be configured via environment variables, command-line options
172
and configurations files. We've started working on unifying this and give
173
access to more options. The first step is a new ``bzr config`` command that
174
can be used to display the active configuration options in the current
175
working tree or branch as well as the ability to set or remove an
176
option. Scripts can also use it to get only the value for a given option.
101
Expected releases for the 2.3 series
102
************************************
104
The 2.3 series has entered the beta phase and 2.3.0 should be released soon
105
enough to be included into Natty Narwhal.
107
As a rough estimate, consider that 2.3.0 will be released in February
108
2011 and be supported until August 2012. Additional releases will be
109
made if critical bugs are encountered
178
112
Further information
179
113
*******************