[RFC] Should we rewrite nested-trees or our formats or punt?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

The current state of play is:
- - brisbane-core will land in a single version that supports nested trees
- - when a repository supports nested trees, some slower code paths are
activated that handle nested trees.
- - in particular, code paths use Tree.iter_references to determine which
subtrees need to be examined, which must walk the tree.

This means that if we land brisbane-core today, it will be slower than
it should be.


Option 1:
Store the data harmoniously with our code paths.

We can store the data about nested trees in an extra CHK tree in
brisbane-core, and we can add special fields to dirstate.  The extra
data will typically be very small.

This feels too late in the release process.

Option 2:
Use a non-subtree variant of brisbane-core

This is simply a stall.

We can land two variants of brisbane-core: one supporting subtrees and
one not supporting them.  The plain brisbane-core format would be
advertised, and the subtree-supporitng format would be hidden and
experimental.  That will restrict the subtree performance issues to
repos that are actually using subtrees.

This means we keep carting around multiple variants, but at least one
will be hidden.

Option 3:
Lie about subtree support

We can land a brisbane-core format that supports subtrees but claims not
 to.  Or alternatively, we can have a config option to enable subtree
support (i.e. in locations.conf).

Option 4:
Change our code to match our storage

Most of these operations are already walking the tree, so in theory, we
can cache the walk and reuse it.  Unfortunately, this would have to be
pushed through several layers.  For example, BzrDir.create_workingtree
does not accept a Tree or iter_entries input.

In my opinion, the resulting code will be less clear than our current
code, harder to debug, etc.  It will also delay nested trees.

Thoughts?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknKnlIACgkQ0F+nu1YWqI2jhQCffVewKzrMFPyN24twHNilbui5
nR8AnR95eF+Gw0x5e4O3V+dplcfhsGWo
=eKl6
-----END PGP SIGNATURE-----