Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Overview

brisbane-core is a project towards a bzr-2.0 repository format that is faster for very large histories and trees. We're aiming for a development format in March 2009 and for it to be the default format by June -- see FormatDeliveryProcess. Most of the effort of the Bazaar core developers is going into this project or the related networking projects.

The primary branch adding the core format has landed in bzr.dev. The format is called development-rich-root. You'll sometimes hear this referred to as "split-inventory" or "content-hashed-keys" (CHK) or the "brisbane-core" format.

To give a very brief technical summary, the new format is more efficient at storing and processing inventories, making many operations faster. The overall disk space is dramatically reduced.

Of course, making a lower level change always has knock-on effects in higher layers, e.g. some stuff slows down and needs some tweaking accordingly. brisbane-core is the integration branch pulling together the new format and the associated tweaks.

The technical changes here comprise:

  • a key-value data structure called CHKMap that records incremental changes to large structures efficiently
  • storing the inventory (dict of present files and directories) in a CHKMap
  • for the file texts stored for revisions, inventory parts and files, use better byte-by-byte delta compression than knit compression

There are three types of work to be done:

  • core engineering
  • integrating them with each other; into brisbane-core; and then into bzr.dev
  • top-to-bottom testing of the bzr stack

Work still to do

all launchpad brisbane-core bugs

Before release as a stable format -- goal June/July 2009

bug 373455 - Stacking support

medium-large

jam working

Performance of commit: currently builds a full inventory then diffs it when nontrivial commit parameters are given - needs changes made to iter_changes to improve. bug 347649

medium, in progress

ian working

Overhead of subtree support

medium to high

Check/fix performance of annotate bug 374726

medium

log DIRECTORY speed bug 374730

small

ian working

Plan and UI for upgrading multiple branches bug 374734

medium

ian working

Plan and UI for upgrading multiple stacked branches bug 374735

medium

Settle on, document and test a best method for upgrades of stacked upgrades; check this will work with Launchpad.

large, risky, in-progress

Fetching from old branches slow bug 374738

large

spiv, lifeless working

Progress reporting for streaming

medium, in progress bug 374740

Dogfood by Bazaar and Launchpad?

medium

Convert & test MySQL

small

Convert & test emacs

small

Measure headline performance numbers

small

Benchmarking

Traffic light report seems to be broken on orcadas and needs to be fixed

small

Configure pre-canned repositories in this format on orcadas

small

Network benchmarks aren't working on orcadas

medium, risky

Launchpad integration (from shortly before beta up to final release)

Test with Launchpad

large, risky

Would be nice to do but not necessary for first release

Performance of initial full-tree commit: writing a full inventory (the initial commit case) is more raw work than with xml

medium, risky

Add a format for groupcompression against texts not included in that group: this would help with the case of multi-megabyte user files, which otherwise need to be written once for each group where they're changed

large, risky

Allow stacking across heterogenous formats, which will make upgrades easier

large, risky

Fix format-handling UI, eg bug 330494

medium

probably post-2.0

Strip unneeded data from groups when sending them

large

Alternate format index for CHK records

medium

probably post 2.0

See also Roadmap/BrisbaneCore/Details and Roadmap/BrisbaneCore/PlusOne