← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/planned-change-integration.txt

https://launchpad.net/bugs/524184
NEWS section template into a separate file

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/planned-change-integration.txt
37
37
   provide strong feedback to the design process for those things which are
38
38
   considered optional or removable, so these APIs should be implemented
39
39
   before removing or making optional existing data.
40
 
 
 
40
 
41
41
 * Deprecating versioned files as a supported API: This collaborates with the
42
42
   Repository API but can probably be done by adding a replacement API for
43
43
   places where the versioned-file api is used. We may well want to keep a
54
54
   layer changes to inventories so while we can create a revision validator
55
55
   API, we cannot create the final one until we have the inventory structural
56
56
   changes completed.
57
 
 
 
57
 
58
58
 * Annotation caching API: This API is a prerequisite for new repository
59
59
   formats. If written after they are introduced we may find that the
60
60
   repository is lacking in functionality, so the API should be implemented
66
66
 
67
67
 * Network-efficient revision graph API: This influences what questions we will
68
68
   want to ask a local repository very quickly; as such it's a driver for the
69
 
   new repository format and should be in place first if possible. It's probably
 
69
   new repository format and should be in place first if possible. Its probably
70
70
   not sufficiently different to local operations to make this a hard ordering
71
71
   though.
72
72
 
73
73
 * Working tree disk ordering: Knowing the expected order for disk operations
74
74
   may influence the needed use case specific APIs, so having a solid
75
75
   understanding of what is optimal - and why - and whether it is pessimal on
76
 
   non-Linux-kernel platforms is rather important.
 
76
   non linux platforms is rather important.
77
77
 
78
78
 * Be able to version files greater than memory in size: This cannot be
79
79
   achieved until all parts of the library which deal with user files are able
87
87
   of the newer API for accessing data about a file over time. It can be a
88
88
   separate step easily; but as it's in the same area of the library should not
89
89
   be done in parallel.
90
 
 
 
90
  
91
91
 * Repository stacking API: The key dependency/change required for this is that
92
92
   repositories must individually be happy with having partial data - e.g. many
93
93
   ghosts. However the way the API needs to be used should be driven from the
94
 
   command layer in, because it's unclear at the moment what will work best.
 
94
   command layer in, because its unclear at the moment what will work best.
95
95
 
96
96
 * Revision stream API: This API will become clear as we streamline commands.
97
97
   On the data insertion side commit will want to generate new data. The
98
98
   commands pull, bundle, merge, push, possibly uncommit will want to copy
99
99
   existing data in a streaming fashion.
100
 
 
101
 
 * New container format: It's hard to tell what the right way to structure the
 
100
 
 
101
 * New container format: Its hard to tell what the right way to structure the
102
102
   layering is. Probably having smooth layering down to the point that code
103
103
   wants to operate on the containers directly will make this more clear. As
104
104
   bundles will become a read-only branch & repository, the smart server wants
129
129
 * Delta storage optimisation: This has a strict dependency on a new repository
130
130
   format. Optimisation takes many forms - we probably cannot complete the
131
131
   desired optimisations under knits though we could use xdelta within a
132
 
   knit-variation.
 
132
   knit-variation. 
133
133
 
134
134
 * Greatest distance from origin cache: The potential users of this exist
135
135
   today, it is likely able to be implemented immediately, but we are not sure
136
136
   that its needed anymore, so it is being shelved.
137
137
 
138
 
 * Removing derivable data: It's very hard to do this while the derived data is
 
138
 * Removing derivable data: Its very hard to do this while the derived data is
139
139
   exposed in API's but not used by commands. Implemented the targeted API's
140
140
   for our core use cases should allow use to remove accidental use of derived
141
141
   data, making only explicit uses of it visible, and isolating the impact of