← 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: Canonical.com Patch Queue Manager
  • Date: 2010-11-11 08:45:19 UTC
  • mfrom: (4597.9.22 reports-conflict-resolved)
  • Revision ID: pqm@pqm.ubuntu.com-20101111084519-bmk1zmblp7kex41a
(vila) More feedback about the conflicts just resolved and the remaining
 ones. (Vincent Ladeuil)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/planned-change-integration.txt
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
 
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
100
 
101
 
 * New container format: It's hard to tell what the right way to structure the
 
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
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