1
=== added file 'doc/developers/nested-trees.txt'
2
--- doc/developers/nested-trees.txt	1970-01-01 00:00:00 +0000
3
+++ doc/developers/nested-trees.txt	2009-05-28 00:35:25 +0000
4
@@ -0,0 +1,88 @@
5
1
Nested Trees
6
2
############
7
3
8
4
Principles
9
5
----------
10
6
- If you branch from a composite tree, you'll have all the data to construct
11
7
  any previous version
12
8
- Never store a location in versioned data.
13
9
- Implementation of nested trees shall not make operations observably slower
14
10
  for those not using nested trees.
15
11
16
12
17
13
Undecided questions
18
14
-------------------
19
15
20
16
Shall commands recurse downwards by default?
21
17
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22
18
Pros:
23
19
 - It is hard to accidentally produce inconsistent trees
24
20
 - Inconsistent trees are hard for remote users to handle
25
21
26
22
Cons:
27
23
 - It is hard to accidentally commit too many things at once
28
24
 - Accidentally committing too many things at once is easy to resolve
29
25
 - Accidentally committing nuclear launch codes is easier to do
30
26
 - More risk of exposing users to bugs
31
27
 - Makes incompleteness more glaring
32
28
 - Annoys users.
33
29
34
30
Shall commands recurse upwards by default?
35
31
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
36
32
37
33
Shall subtree branches be addressable?
38
34
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39
35
40
36
Shall we model nested trees as a composite tree?
41
37
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
42
38
43
39
Shall we use root-ids for tree references?
44
40
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
45
41
46
42
Shall we recurse our low-level operations from the beginning?
47
43
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
48
44
Pros:
49
45
 - We may not need extra indices
50
46
Cons:
51
47
 - It may take longer to implement and needlessly distort the code
52
48
53
49
Shall we lock recursively?
54
50
~~~~~~~~~~~~~~~~~~~~~~~~~~
55
51
Pros:
56
52
 - Matches existing behaviour by failing earlier
57
53
Cons:
58
54
 - Slower
59
55
 - Fails needlessly
60
56
61
57
How do we handle merge when the subtree hasn't made any changes?
62
58
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
63
59
64
60
What should uncommit do?
65
61
~~~~~~~~~~~~~~~~~~~~~~~~
66
62
67
63
Shall we use a CompositeTree object as a shim to make existing commands work?
68
64
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
69
65
70
66
Some subtrees should have commits and some should not.  How?
71
67
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
72
68
73
69
Decided questions
74
70
-----------------
75
71
76
72
The branches of subtrees shall share a repository with the containing tree.
77
73
78
74
The branches of subtrees shall be in a special format that shares a single
79
75
last_revision file that is stored in the containing branch.
80
76
81
77
The subtree branches shall be referenced in the last_revision file by file-id.
82
78
83
79
Subtree branches shall not support individual configuration.
84
80
85
81
Fetch shall automatically fetch the revisions mentioned by tree-references,
86
82
recursively.
87
83
88
84
The reserved revision-id "head:" shall be used in tree-references to refer to
89
85
the tip revision of a branch.
90
86
91
87
bzr-svn repositories with externals shall behave as though the multiple
92
88
repositories were a single Bazaar repository with multiple branches.
Status:	Rejected
Rejected by:	Aaron Bentley on 2009-05-28
Proposed branch:	lp:~abentley/bzr/nested-specs
Merge into:	lp:~bzr/bzr/trunk-old
Diff against target:	92 lines
To merge this branch:	bzr merge lp:~abentley/bzr/nested-specs
Related bugs:	Link a bug report
Reviewer	Review Type	Date Requested	Status
Martin Pool		2009-05-27	Approve on 2009-05-27
Review via email: mp+6817@code.launchpad.net