bzr 2.1.0b2

Codename:a load off my mind

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)


  • 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)


  • 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)


  • 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 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)

Table Of Contents

Previous topic

bzr 2.1.0b3

Next topic

bzr 2.0.2

This Page