bzr 2.1.0b2
###########

:Codename: a load off my mind
:2.1.0b2: 2009-11-02

This is our second feature-filled release since 2.0, pushing us down the
path to a 2.1.0. Once again, all bugfixes in 2.0.2 are present in 2.1.0b2.

Key highlights in this release are: improved handling of
failures-during-cleanup for commit, fixing a long-standing bug with
``bzr+http`` and shared repositories, all ``lp:`` urls to be resolved
behind proxies, and a new StaticTuple datatype, allowing us to reduce
memory consumption (50%) and garbage collector overhead (40% faster) for
many operations.

* A new ``--concurrency`` option has been added as well as an associated
  BZR_CONCURRENCY environment variable to specify the number of
  processes that can be run concurrently when running ``bzr selftest``. The
  command-line option overrides the environment variable if both are
  specified. If none is specified. the number of processes is obtained
  from the OS as before.  (Matt Nordhoff, Vincent Ladeuil)

Bug Fixes
*********

* ``bzr+http`` servers no longer give spurious jail break errors when
  serving branches inside a shared repository.  (Andrew Bennetts, #348308)

* Errors during commit are handled more robustly so that knock-on errors
  are less likely to occur, and will not obscure the original error if
  they do occur.  This fixes some causes of ``TooManyConcurrentRequests``
  and similar errors.  (Andrew Bennetts, #429747, #243391)

* Launchpad urls can now be resolved from behind proxies.
  (Gordon Tyler, Vincent Ladeuil, #186920)

* Reduce the strictness for StaticTuple, instead add a debug flag
  ``-Dstatic_tuple`` which will change apis to be strict and raise errors.
  This way, most users won't see failures, but developers can improve
  internals. (John Arbash Meinel, #471193)

* TreeTransform.adjust_path updates the limbo paths of descendants of adjusted
  files.  (Aaron Bentley)

* Unicode paths are now handled correctly and consistently by the smart
  server.  (Andrew Bennetts, Michael Hudson, #458762)

Improvements
************

* When reading index files, we now use a ``StaticTuple`` rather than a
  plain ``tuple`` object. This generally gives a 20% decrease in peak
  memory, and can give a performance boost up to 40% on large projects.
  (John Arbash Meinel)

* Peak memory under certain operations has been reduced significantly.
  (eg, 'bzr branch launchpad standalone' is cut in half)
  (John Arbash Meinel)

Documentation
*************

* Filtered views user documentation upgraded to refer to format 2a
  instead of pre-2.0 formats. (Ian Clatworthy)

API Changes
***********

* Remove deprecated ``CLIUIFactory``.  (Martin Pool)

* ``UIFactory`` now has new ``show_error``, ``show_message`` and
  ``show_warning`` methods, which can be hooked by non-text UIs.  
  (Martin Pool)

Internals
*********

* Added ``bzrlib._simple_set_pyx``. This is a hybrid between a Set and a
  Dict (it only holds keys, but you can lookup the object located at a
  given key). It has significantly reduced memory consumption versus the
  builtin objects (1/2 the size of Set, 1/3rd the size of Dict). This is
  used as the interning structure for StaticTuple objects.
  (John Arbash Meinel)

* ``bzrlib._static_tuple_c.StaticTuple`` is now available and used by
  the btree index parser and the chk map parser. This class functions
  similarly to ``tuple`` objects. However, it can only point to a limited
  collection of types.  (Currently StaticTuple, str, unicode, None, bool,
  int, long, float, but not subclasses).  This allows us to remove it from
  the garbage collector (it cannot be in a cycle), it also allows us to
  intern the objects. In testing, this can reduce peak memory by 20-40%,
  and significantly improve performance by removing objects from being
  inspected by the garbage collector.  (John Arbash Meinel)

* ``GroupCompressBlock._ensure_content()`` will now release the
  ``zlib.decompressobj()`` when the first request is for all of the
  content. (Previously it would only be released if you made a request for
  part of the content, and then all of it later.) This turns out to be a
  significant memory savings, as a ``zstream`` carries around approx 260kB
  of internal state and buffers. (For branching bzr.dev this drops peak
  memory from 382MB => 345MB.) (John Arbash Meinel)

* When streaming content between ``2a`` format repositories, we now clear
  caches from earlier versioned files. (So 'revisions' is cleared when we
  start reading 'inventories', etc.) This can have a significant impact on
  peak memory for initial copies (~200MB). (John Arbash Meinel)


