← 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-09-29 22:03:03 UTC
  • mfrom: (5416.2.6 jam-integration)
  • Revision ID: pqm@pqm.ubuntu.com-20100929220303-cr95h8iwtggco721
(mbp) Add 'break-lock --force'

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/planned-change-integration.txt
11
11
integrate because we will often need to alter apis throughout the code base to
12
12
expose the increased or reduced model of the preferred disk format.
13
13
 
14
 
The dot file performance.dot graphs out the dependencies to let us make
15
 
accurate assessments of the changes needed in terms of code and API, hopefully
16
 
minimising the number of different integration steps we have to take, while
17
 
giving us a broad surface area for development. Its based on a sumary in the
18
 
next section of this document of the planned changes with their expected
19
 
collaborators and dependencies. Where a command is listed, the expectation is
20
 
that all uses of that command - local, remote, dumb transport and smart
21
 
transport are being addressed together.
 
14
You can generate a graph ``performance.png`` in the source tree from
 
15
Graphviz "dot" file ``performance.dot``.  This graphs out the dependencies
 
16
to let us make accurate assessments of the changes needed in terms of code
 
17
and API, hopefully minimising the number of different integration steps we
 
18
have to take, while giving us a broad surface area for development. It's
 
19
based on a summary in the next section of this document of the planned
 
20
changes with their expected collaborators and dependencies. Where a
 
21
command is listed, the expectation is that all uses of that command -
 
22
local, remote, dumb transport and smart transport are being addressed
 
23
together.
22
24
 
23
25
 
24
26
The following provides a summary of the planned changes and their expected
35
37
   provide strong feedback to the design process for those things which are
36
38
   considered optional or removable, so these APIs should be implemented
37
39
   before removing or making optional existing data.
38
 
 
 
40
 
39
41
 * Deprecating versioned files as a supported API: This collaborates with the
40
42
   Repository API but can probably be done by adding a replacement API for
41
43
   places where the versioned-file api is used. We may well want to keep a
52
54
   layer changes to inventories so while we can create a revision validator
53
55
   API, we cannot create the final one until we have the inventory structural
54
56
   changes completed.
55
 
 
 
57
 
56
58
 * Annotation caching API: This API is a prerequisite for new repository
57
59
   formats. If written after they are introduced we may find that the
58
60
   repository is lacking in functionality, so the API should be implemented
71
73
 * Working tree disk ordering: Knowing the expected order for disk operations
72
74
   may influence the needed use case specific APIs, so having a solid
73
75
   understanding of what is optimal - and why - and whether it is pessimal on
74
 
   non linux platforms is rather important.
 
76
   non-Linux-kernel platforms is rather important.
75
77
 
76
78
 * Be able to version files greater than memory in size: This cannot be
77
79
   achieved until all parts of the library which deal with user files are able
85
87
   of the newer API for accessing data about a file over time. It can be a
86
88
   separate step easily; but as it's in the same area of the library should not
87
89
   be done in parallel.
88
 
  
 
90
 
89
91
 * Repository stacking API: The key dependency/change required for this is that
90
92
   repositories must individually be happy with having partial data - e.g. many
91
93
   ghosts. However the way the API needs to be used should be driven from the
95
97
   On the data insertion side commit will want to generate new data. The
96
98
   commands pull, bundle, merge, push, possibly uncommit will want to copy
97
99
   existing data in a streaming fashion.
98
 
 
 
100
 
99
101
 * New container format: Its hard to tell what the right way to structure the
100
102
   layering is. Probably having smooth layering down to the point that code
101
103
   wants to operate on the containers directly will make this more clear. As
127
129
 * Delta storage optimisation: This has a strict dependency on a new repository
128
130
   format. Optimisation takes many forms - we probably cannot complete the
129
131
   desired optimisations under knits though we could use xdelta within a
130
 
   knit-variation. 
 
132
   knit-variation.
131
133
 
132
134
 * Greatest distance from origin cache: The potential users of this exist
133
135
   today, it is likely able to be implemented immediately, but we are not sure