~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/whats-new/whats-new-in-2.3.txt

  • Committer: Patch Queue Manager
  • Date: 2013-05-20 17:46:29 UTC
  • mfrom: (6573.1.1 bzr)
  • Revision ID: pqm@pqm.ubuntu.com-20130520174629-dp7zujtuclvomuzd
(jameinel) Fix CVE 2013-2009. Avoid allowing multiple wildcards in a single
 SSL cert hostname segment. (Andrew Starr-Bochicchio)

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
What's New in Bazaar 2.3?
3
3
*************************
4
4
 
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.
 
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.)
 
10
 
 
11
This document accumulates a high level summary of what's changed.
7
12
See the
8
13
:doc:`../release-notes/index` for a full list.
9
14
 
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
14
 
those upgrading.
15
 
 
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
18
 
previous versions.
 
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.
 
19
 
 
20
Bazaar 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5
 
21
versions that weren't included in 2.3.0 and fixes some bugs on its own.
 
22
 
 
23
Bazaar 2.3.2 is a bugfix release that was never released.
 
24
 
 
25
Bazaar 2.3.3 is a bugfix release including the fixes in 2.3.2 and
 
26
fixing the test helpers deprecated by python-2.7.
 
27
 
 
28
Bazaar 2.3.4 is a bugfix release.
 
29
 
 
30
See the :doc:`../release-notes/index` for details.
 
31
 
 
32
Bazaar 2.3 is fully compatible both locally and on the network with 2.0, 2.1,
 
33
and 2.2. It can read and write repositories generated by all previous
 
34
versions.
19
35
 
20
36
Changed Behaviour
21
37
*****************
22
38
 
 
39
* Committing a new revision in a stacked branch is now supported, as long as
 
40
  you are using the current repository format (2a). It will preserve the
 
41
  stacking invariants, etc, so that fetching after commit is guaranteed to
 
42
  work. (John Arbash Meinel, #375013)
 
43
 
 
44
* Support for some old development formats have been removed:
 
45
  ``development-rich-root``, ``development6-rich-root``, and
 
46
  ``development7-rich-root``.  These formats were always labelled experimental
 
47
  and not used unless the user specifically asked for them.  If you have
 
48
  repositories using these old formats you should upgrade them to ``2a`` using
 
49
  Bazaar 2.2.  (Andrew Bennetts)
 
50
 
23
51
* The default ``ignore`` file created by Bazaar will contain ``__pycache__``,
24
52
  which is the name of the directory that will be used by Python to store
25
53
  bytecode files.
26
54
  (Andrea Corbellini, #626687)
27
55
 
 
56
* The default sort order for the ``bzr tags`` command now uses a natural sort
 
57
  where numeric substrings are sorted numerically.  The previous default was
 
58
  "asciibetical" where tags were sorted by the characters they contained.  To
 
59
  get the old behavior, one can use ``bzr tags --sort=alpha``.
 
60
  (Neil Martinsen-Burrell, #640760)
 
61
 
 
62
* On platforms other than Windows and Mac OS X, Bazaar will use configuration
 
63
  files that live in $XDG_CONFIG_HOME/bazaar if that directory exists.  This
 
64
  allows interested individuals to conform to the XDG Base Directory
 
65
  specification.  The plugin location has not changed and is still
 
66
  ~/.bazaar/plugins.  To use a different directory for plugins, use the
 
67
  environment variable BZR_PLUGIN_PATH.  (Neil Martinsen-Burrell, #195397)
 
68
 
 
69
* ``bzr upgrade`` now operates recursively when run on a shared
 
70
  repository, automatically upgrading the branches within it, and has
 
71
  grown additional options for showing what it will do and cleaning up
 
72
  after itself.  (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
 
73
 
28
74
Launchpad integration
29
75
*********************
30
76
 
33
79
  ``bzr launchpad-login user && bzr push lp:~/project/branch`` will now
34
80
  push to ``lp:~user/project/branch``.  (John Arbash Meinel)
35
81
 
 
82
* Launchpad has announced that the ``edge.launchpad.net`` instance is
 
83
  deprecated and may be shut down in the future
 
84
  <http://blog.launchpad.net/general/edge-is-deprecated>.  Bazaar has therefore
 
85
  been updated in this release to talk to the main (``launchpad.net``) servers,
 
86
  rather than the ``edge`` ones.
 
87
 
36
88
Performance improvements
37
89
************************
38
90
 
43
95
* ``bzr send`` uses less memory.
44
96
  (John Arbash Meinel, #614576)
45
97
 
 
98
* Fetches involving stacked branches and branches with tags now do slightly less
 
99
  I/O, and so does branching from an existing branch.  This also improves the
 
100
  network performance of these operations.  (Andrew Bennetts)
 
101
 
46
102
* Inventory entries now consume less memory (on 32-bit Ubuntu file entries
47
103
  have dropped from 68 bytes to 40, and directory entries from 120 bytes
48
104
  to 48).  This affects most operations, and depending on the size of the
84
140
  ``bzr log -vp -r mainline:annotate:bzrlib/transform.py:500``
85
141
  (Aaron Bentley)
86
142
 
 
143
Testing/Bug reporting
 
144
*********************
 
145
 
 
146
* Shell-like scripts can now be run directly from the command line without
 
147
  writing a python test. This should help users adding reproducing recipes
 
148
  to bug reports. (Vincent Ladeuil)
 
149
 
 
150
 
 
151
Improved conflict handling
 
152
**************************
 
153
 
 
154
* ``pull``, ``merge`` or ``switch`` can lead to conflicts when deleting a
 
155
  versioned directory contains unversioned files. The cause of the conflict
 
156
  is that deleting the directory will orphan the unversioned files so the
 
157
  user needs to instruct ``bzr`` what do to do about these orpahns. This is
 
158
  controlled by setting the ``bzr.transform.orphan_policy`` configuration
 
159
  variable with a value of ``move``. In this case the unversioned files are
 
160
  moved to a ``bzr-orphans`` directory at the root of the working tree. The
 
161
  default behaviour is specified (if needed) by setting the variable to
 
162
  ``conflict``.  (Vincent Ladeuil, #323111)
 
163
 
 
164
* ``bzr resolve --take-this`` and ``bzr resolve --take-other`` can now be
 
165
  used for text conflicts. This will ignore the differences that were merged
 
166
  cleanly and replace the file with its content in the current branch
 
167
  (``--take-this``) or with its content in the merged branch
 
168
  (``--take-other``). (Vincent Ladeuil, #638451)
 
169
 
 
170
* ``bzr resolve`` now provides more feedback about the conflicts just
 
171
  resolved and the remaining ones. (Vincent Ladeuil)
 
172
 
87
173
Documentation
88
174
*************
89
175
 
91
177
  format, used by emacs and the standalone ``info`` reader.
92
178
  (Vincent Ladeuil, #219334)
93
179
 
 
180
Configuration
 
181
*************
 
182
 
 
183
``bzr`` can be configured via environment variables, command-line options
 
184
and configurations files. We've started working on unifying this and give
 
185
access to more options. The first step is a new ``bzr config`` command that
 
186
can be used to display the active configuration options in the current
 
187
working tree or branch as well as the ability to set or remove an
 
188
option. Scripts can also use it to get only the value for a given option.
94
189
 
95
190
Further information
96
191
*******************