Merge lp:~abentley/bzr/nested-specs into lp:~bzr/bzr/trunk-old

[Aaron Bentley]

[Aaron Bentley (abentley)]

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

Here's a document representing the current thinking on nested trees, as
I understand it.

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

iEYEARECAAYFAkodFa0ACgkQ0F+nu1YWqI3oRQCfafCgzgQynMc8WrJWbi5flMxY
OVoAn3qXNPiKNkr9yxH6513naSiM+yin
=IMyQ
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

That's good information. But maybe this would be better in devnotes than in trunk while we're still working through it.

review: Approve

[lp:~abentley/bzr/nested-specs]

4382. By Aaron Bentley on 2009-05-27

Updated doc

4383. By Aaron Bentley on 2009-05-27

Add other questions.

Unmerged revisions

4383. By Aaron Bentley on 2009-05-27

Add other questions.

4382. By Aaron Bentley on 2009-05-27

Updated doc

4381. By Aaron Bentley on 2009-05-27

First pass at a nested trees doc.

4380. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-25

(igc) two simple log dotted revno tests (Marius Kruger)

4379. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-23

(tanner) merge 1.15final back to trunk

4378. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-22

(igc) faster branch in a shared repo for dev6rr format (Ian
 Clatworthy)

4377. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-22

(igc) make branch --no-tree faster (Ian Clatworthy)

4376. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-21

(Jelmer) Return BranchPushResult from InterBranch.lossy_push().

4375. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-21

(Jelmer) Add child_submit_format option used by 'bzr send'.

4374. By Canonical.com Patch Queue Manager <email address hidden> on 2009-05-20

(abentley) Enable committing from a PreviewTree.

=== added file 'doc/developers/nested-trees.txt'
--- doc/developers/nested-trees.txt	1970-01-01 00:00:00 +0000
+++ doc/developers/nested-trees.txt	2009-05-28 00:35:25 +0000
@@ -0,0 +1,88 @@
+Nested Trees
+############
+
+Principles
+----------
+- If you branch from a composite tree, you'll have all the data to construct
+  any previous version
+- Never store a location in versioned data.
+- Implementation of nested trees shall not make operations observably slower
+  for those not using nested trees.
+
+
+Undecided questions
+-------------------
+
+Shall commands recurse downwards by default?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Pros:
+ - It is hard to accidentally produce inconsistent trees
+ - Inconsistent trees are hard for remote users to handle
+
+Cons:
+ - It is hard to accidentally commit too many things at once
+ - Accidentally committing too many things at once is easy to resolve
+ - Accidentally committing nuclear launch codes is easier to do
+ - More risk of exposing users to bugs
+ - Makes incompleteness more glaring
+ - Annoys users.
+
+Shall commands recurse upwards by default?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Shall subtree branches be addressable?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Shall we model nested trees as a composite tree?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Shall we use root-ids for tree references?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Shall we recurse our low-level operations from the beginning?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Pros:
+ - We may not need extra indices
+Cons:
+ - It may take longer to implement and needlessly distort the code
+
+Shall we lock recursively?
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+Pros:
+ - Matches existing behaviour by failing earlier
+Cons:
+ - Slower
+ - Fails needlessly
+
+How do we handle merge when the subtree hasn't made any changes?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+What should uncommit do?
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Shall we use a CompositeTree object as a shim to make existing commands work?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some subtrees should have commits and some should not.  How?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Decided questions
+-----------------
+
+The branches of subtrees shall share a repository with the containing tree.
+
+The branches of subtrees shall be in a special format that shares a single
+last_revision file that is stored in the containing branch.
+
+The subtree branches shall be referenced in the last_revision file by file-id.
+
+Subtree branches shall not support individual configuration.
+
+Fetch shall automatically fetch the revisions mentioned by tree-references,
+recursively.
+
+The reserved revision-id "head:" shall be used in tree-references to refer to
+the tip revision of a branch.
+
+bzr-svn repositories with externals shall behave as though the multiple
+repositories were a single Bazaar repository with multiple branches.