← 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: Patch Queue Manager
  • Date: 2016-04-21 05:06:57 UTC
  • mfrom: (6603.4.1 bzr)
  • Revision ID: pqm@pqm.ubuntu.com-20160421050657-ygnzfybewvudf1j9
(richard-wilbur) Use initial_comment as commit_message for lp_propose.(Shawn
 Wang) (Shawn Wang)

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. Its probably
 
69
   new repository format and should be in place first if possible. It's 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 platforms is rather important.
 
76
   non-Linux-kernel 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
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 its unclear at the moment what will work best.
 
94
   command layer in, because it's 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: Its hard to tell what the right way to structure the
 
101
 * New container format: It's 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: Its very hard to do this while the derived data is
 
138
 * Removing derivable data: It's 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