← 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: Vincent Ladeuil
  • Date: 2009-04-27 16:10:10 UTC
  • mto: (4310.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4311.
  • Revision ID: v.ladeuil+lp@free.fr-20090427161010-7swfzeagf63cpixd
Fix bug #367726 by reverting some default user handling introduced
while fixing bug #256612.

* bzrlib/transport/ssh.py:
(_paramiko_auth): Explicitly use getpass.getuser() as default
user.

* bzrlib/transport/ftp/_gssapi.py:
(GSSAPIFtpTransport._create_connection): Explicitly use
getpass.getuser() as default user.

* bzrlib/transport/ftp/__init__.py:
(FtpTransport._create_connection): Explicitly use
getpass.getuser() as default user.

* bzrlib/tests/test_sftp_transport.py:
(TestUsesAuthConfig.test_sftp_is_none_if_no_config)
(TestUsesAuthConfig.test_sftp_doesnt_prompt_username): Revert to
None as the default user.

* bzrlib/tests/test_remote.py:
(TestRemoteSSHTransportAuthentication): The really offending one:
revert to None as the default user.

* bzrlib/tests/test_config.py:
(TestAuthenticationConfig.test_username_default_no_prompt): Update
test (and some PEP8).

* bzrlib/smtp_connection.py:
(SMTPConnection._authenticate): Revert to None as the default
user.

* bzrlib/plugins/launchpad/account.py:
(_get_auth_user): Revert default value handling.

* bzrlib/config.py:
(AuthenticationConfig.get_user): Fix doc-string. Leave default
value handling to callers.

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
 
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.
 
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.
24
22
 
25
23
 
26
24
The following provides a summary of the planned changes and their expected
37
35
   provide strong feedback to the design process for those things which are
38
36
   considered optional or removable, so these APIs should be implemented
39
37
   before removing or making optional existing data.
40
 
 
 
38
 
41
39
 * Deprecating versioned files as a supported API: This collaborates with the
42
40
   Repository API but can probably be done by adding a replacement API for
43
41
   places where the versioned-file api is used. We may well want to keep a
54
52
   layer changes to inventories so while we can create a revision validator
55
53
   API, we cannot create the final one until we have the inventory structural
56
54
   changes completed.
57
 
 
 
55
 
58
56
 * Annotation caching API: This API is a prerequisite for new repository
59
57
   formats. If written after they are introduced we may find that the
60
58
   repository is lacking in functionality, so the API should be implemented
73
71
 * Working tree disk ordering: Knowing the expected order for disk operations
74
72
   may influence the needed use case specific APIs, so having a solid
75
73
   understanding of what is optimal - and why - and whether it is pessimal on
76
 
   non-Linux-kernel platforms is rather important.
 
74
   non linux platforms is rather important.
77
75
 
78
76
 * Be able to version files greater than memory in size: This cannot be
79
77
   achieved until all parts of the library which deal with user files are able
87
85
   of the newer API for accessing data about a file over time. It can be a
88
86
   separate step easily; but as it's in the same area of the library should not
89
87
   be done in parallel.
90
 
 
 
88
  
91
89
 * Repository stacking API: The key dependency/change required for this is that
92
90
   repositories must individually be happy with having partial data - e.g. many
93
91
   ghosts. However the way the API needs to be used should be driven from the
97
95
   On the data insertion side commit will want to generate new data. The
98
96
   commands pull, bundle, merge, push, possibly uncommit will want to copy
99
97
   existing data in a streaming fashion.
100
 
 
 
98
 
101
99
 * New container format: Its hard to tell what the right way to structure the
102
100
   layering is. Probably having smooth layering down to the point that code
103
101
   wants to operate on the containers directly will make this more clear. As
129
127
 * Delta storage optimisation: This has a strict dependency on a new repository
130
128
   format. Optimisation takes many forms - we probably cannot complete the
131
129
   desired optimisations under knits though we could use xdelta within a
132
 
   knit-variation.
 
130
   knit-variation. 
133
131
 
134
132
 * Greatest distance from origin cache: The potential users of this exist
135
133
   today, it is likely able to be implemented immediately, but we are not sure
141
139
   data, making only explicit uses of it visible, and isolating the impact of
142
140
   removing it : allowing us to experiment sensibly. This covers both dropping
143
141
   the per-file merge graph and the hash-based-names proposals.
 
142
 
 
143
.. _`Performance Tasks`: performance.png