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.
14
`Performance Tasks`_, which is generated from the Graphviz "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. It's based on a summary 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
24
26
The following provides a summary of the planned changes and their expected
139
141
data, making only explicit uses of it visible, and isolating the impact of
140
142
removing it : allowing us to experiment sensibly. This covers both dropping
141
143
the per-file merge graph and the hash-based-names proposals.
143
.. _`Performance Tasks`: performance.png
added
removed
doc/developers/planned-change-integration.txt
