← 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

  • Committer: John Arbash Meinel
  • Date: 2010-02-17 17:11:16 UTC
  • mfrom: (4797.2.17 2.1)
  • mto: (4797.2.18 2.1)
  • mto: This revision was merged to the branch mainline in revision 5055.
  • Revision ID: john@arbash-meinel.com-20100217171116-h7t9223ystbnx5h8
merge bzr.2.1 in preparation for NEWS entry.

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
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
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
 
 
 
100
 
101
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
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