bzr 1.14 release schedule and manager

[Robert Collins]

On Sun, 2009-03-22 at 08:57 -0400, David Reitter wrote:
> Robert Collins, on 2009-03-20:
> > Our previous experience is that folk don't differentiate between our  
> > formats well, so while we can say no guarantees, and don't-use-this,  
> > it isn't what happens. We pay a very high price when someone shoots  
> > themselves in the foot with pre-beta formats.
> 
> This may have to do with the fact that the Bzr reference does not  
> explain different formats and only gives rough guidelines.
> 
> I'd very much like to see these things documented better.  A couple of  
> suggestions regarding what appears to be missing from the documentation.
> 
> "bzr help current-formats" does not list what's recommended.  For  
> example, you told me today that "rich-root's are not the recommended  
> production format.".   The documentation does not explain what the  
> disadvantage of 1.9-rich-root would be.

One goal we have is to have the formats be optional knowledge - users
shouldn't *need* to know about them. Due to them not being all
interchangeable though, this is hard to achieve without a surprise
occuring at some point, when (for instance) a slow merge occurs. Long
term we want to get down to a very small number of formats - probably
one..

Formats exist to separate out already shipped behaviour, and new
behaviours. The flavours of formats have a several different bits:
 - on the repository
  - supporting stacking
  - supporting rich roots
  - supporting subtrees
 - on the branch
  - being a loom
  - supporting stacking
 - on the tree
  - supporting tree filtering

In a separate dimension we're continually working to improve
performance.

Now, all the formats listed in 'bzr help current-formats' are fully
supported [as long as they are from bzr itself and not an arbitrary
third-party plugin :)]. However there are computation issues in moving
data from one format to another where the repository part of the format
is different. When the repository is identical its basically a massive
block-copy with integrity checking. When the source doesn't support rich
roots, every commit has to be reserialised (just the metadata, but that
can be large - like 2MB per commit in large trees before delta
compression) to add the rich root data.

> The same text relies on non-user-level terminology.  I shouldn't need  
> to know about "dirstate tags". "rich-root" is not explained (only in  
> the reference), and I only understand from this that it's needed for  
> SVN interoperability.

I certainly agree; there is some history here though - bzr-svn started
using a beta format before it was moved out of beta; ideally we wouldn't
have the situation we have today... but sadly we do have it.

> What are the efficiency advantages of the formats?

Ignoring the pre-bzr 1.0 formats :):
 - pack-0.92 uses bisectable flat index files and packed files with
   single parent delta compression and whole-file inventories.
 - 1.6(-*) is the same disk format, but logic changes were added to
   support stacking.
 - 1.9(-*) uses a B+Tree index with fixed size pages, which gives much
   more predicatable IO and a 100 times improvement in fan out over 
   bisection, and does not change the delta compression or inventory
   representation.

The new format we're working on changes both the delta compression and
inventory representation, to get a 2-3:1 reduction in storage size, and
some operations get up to 20 times faster. (such as log -v).

>    I learned today  
> that some operations become unusably slow when they need to convert  
> between formats on the fly (and many revisions are present).  I wonder  
> if that applies to merges as well.  Similarly, stacked branches have  
> format requirements (1.9, isn't it).  Is that documented?

Yes, it is - stacking requires a bzr 1.6 or newer format, as shown in
bzr help current-formats. If you ask for stacking bzr will upgrade if
needed on its own. Merge has a fetch built into it, and if the formats
are different it will need to convert.

> Generally: which guarantees / promises does the Bazaar project give  
> regarding future conversion between formats?

For:
 - plain->(rich-root|subtrees), its a one-way conversion.
 - all other formats are bidirectional.

HTH,
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090323/5cac01ba/attachment.pgp