~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: Canonical.com Patch Queue Manager
  • Date: 2011-07-11 02:46:35 UTC
  • mfrom: (6017.1.2 test-isolation-speed)
  • Revision ID: pqm@pqm.ubuntu.com-20110711024635-f39c8kz23s347m1t
(spiv) Speed up TestCaseWithMemoryTransport._check_safety_net by reading the
 dirstate file directly rather than using WorkingTree.open(). (Andrew
 Bennetts)

Show diffs side-by-side

added added

removed removed

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