« back to all changes in this revision
Viewing changes to doc/developers/new-config-rationale.txt
- browse files at revision 6378
- compare with another revision
- compare with revision 6079
- download diff
- download tarball
- view history from revision 6378
- Committer: Patch Queue Manager
- Date: 2011-12-15 18:38:46 UTC
- mfrom: (6362.3.2 config-explained)
- Revision ID: pqm@pqm.ubuntu.com-20111215183846-l332p0xr8hy0ekhf
(vila) More documentation about the new config implementation. (Vincent
Ladeuil)
Ladeuil)
added
removed
doc/developers/new-config-rationale.txt
60
60
61
61
* should the option be inherited by more specific sections, (this was more
62
62
or less the default in the old design, it is addressed by section
63
matchers in the new one).
63
matchers in the new one by letting users define options in whatever
64
relevant section and let the matcher select the right ones).
64
65
65
* should the inherited value append the relative path between the
66
section one and the location it applies to (see http://pad.lv/832013),
66
* should the inherited value append the relative path between the section
67
one and the location it applies to (see http://pad.lv/832013, fixed),
67
68
68
69
* the default value (including calling any python code that may be
69
required to calculate this value)(see http://pad.lv/832064),
70
required to calculate this value)(see http://pad.lv/832064, fixed),
70
71
71
72
* priority between sections in various config files (this is defined by
72
73
the section matcher associated with a given config store for stacks,
78
79
inconsistent. (Using only Stacks addresses that).
79
80
80
81
* Access to the 'active' configuration option value from the command line
81
doesn't give access to the specific section. (This is only a concern if
82
the user has no other way to address a specific configuration option
83
including Store and Section when using ``bzr config``) (see http://pad.lv/725234).
82
doesn't give access to the specific section. This is a concern if the user
83
has no other way to address a specific configuration option including
84
Store and Section when using ``bzr config`` (see
85
http://pad.lv/725234). Plugins defining their own stacks and/or stores
86
also have no way to properly plug into ``bzr config`` (see
87
http://pad.lv/788991).
84
88
85
89
* Rules for configuration options are not clearly defined for remote
86
90
branches (they may differ between dumb and smart servers the former will
91
95
accessible to plugin authors either by supporting plugin configuration
92
96
options in the configuration files or allowing the plugins to define their
93
97
own configuration files. (Separating Section, Store and Stack starts
94
addressing that, a stack registry should complete the needed means).
98
addressing that, a stack registry should complete the needed means
99
http://pad.lv/832036).
95
100
96
101
* While the actual configuration files support sections, they are used in
97
102
mutually exclusive ways that make it impossible to offer the same set of
111
116
112
117
* ``branch.conf`` doesn't use any section.
113
118
119
This is addressed by defining different stacks selecting the relevant
120
sections from the stores involved. ``ALIASES`` for example can define a
121
stack that select only the ``ALIASES`` section from ``bazaar.conf``.
122
114
123
* There is no easy way to get configuration options for a given repository
115
124
or an arbitrary path. Working trees and branches are generally organized
116
125
in hierarchies and being able to share the option definitions is an often
120
129
support conflict resolution options for a given file, directory or
121
130
subtree (see http://pad.lv/359320).
122
131
123
* Since sections allow different definitions for the same option, a total
124
order should be defined between sections to select the right definition
125
for a given context (paths or globs for ``locations.conf`` but other
126
schemes can be used, window names for qbzr for example). Allowing globs
127
for section names is harmful in this respect since the order is currently
128
defined as being the lexicographical one. The caveat here is that if the
129
order is always defined for a given set of sections it can change when one
130
or several globs are modified and the user may get surprising and unwanted
131
results in these cases. The lexicographical order is otherwise fine to
132
define what section is more specific than another. (This may not be a
133
problem in real life since longer globs are generally more specific than
134
shorter ones and explicit paths should also be longer than matching
132
* Since sections allow different definitions for the same option (in the
133
same store), a total order should be defined between sections to select
134
the right definition for a given context (paths or globs for
135
``locations.conf`` but other schemes can be used, window names for qbzr,
136
repository UUIDs for bzr-svn for example). Allowing globs for section
137
names is harmful in this respect since the order is currently defined as
138
being based on the number of path components. The caveat here is that if
139
the order is always defined for a given set of sections it can change when
140
one or several globs are modified and the user may get surprising and
141
unwanted results in these cases. The lexicographical order is otherwise
142
fine to define what section is more specific than another. (This may not
143
be a problem in real life since longer globs are generally more specific
144
than shorter ones and explicit paths should also be longer than matching
135
145
globs. That may leave a glob and a path of equal length in a gray area but
136
146
in practice using ``bzr config`` should give enough feedback to address
137
them. See also http://pad.lv/832046 asking for a less magical section matcher).
147
them. See also http://pad.lv/832046 asking for a less magical section
148
matcher).
138
149
139
150
* Internally, configuration files (and their fallbacks, ``bazaar.conf`` and
140
151
``locations.conf`` for ``branch.conf``) are read every time *one* option is
144
155
145
156
* The current implementation use a mix of transport-based and direct file
146
157
systems operations (Addressed by Store implementation relying on
147
transports only).
158
transports only and the hpss implementing the corresponding verbs).
148
159
149
160
* While the underlying ``ConfigObj`` implementation provides an
150
161
interpolation feature, the ``bzrlib`` implementation doesn't provide an
151
162
easy handling of templates where other configuration options can be
152
163
interpolated. Instead, ``locations.conf`` (and only it) allows for
153
``appendpath`` and ``norecurse``. (Partially implemented, cross-section
154
and cross-file interpolation still to be implemented, see
155
http://pad.lv/832013 for the remaining parts).
164
``appendpath`` and ``norecurse``. (Cross-section, cross-file interpolation
165
and section local options are now implemented in the new design).
156
166
157
167
* Inherited list values can't be modified, a more specific configuration can
158
168
only redefine the whole list.
188
198
Naming
189
199
------
190
200
191
Option names are organized into a name space for a given configuration file
192
(or a set of related configuration files). One such set includes
193
``bazaar.conf``, ``locations.conf``, ``branch.conf``, etc. Plugins can
194
define their own sets for their own needs.
201
Option names are organized into a name space for a given stack. One such set
202
includes ``bazaar.conf``, ``locations.conf``, ``branch.conf``, etc. Plugins
203
can define their own sets for their own needs. While it is conceivable that
204
the same option name can be used in unrelated configuration stacks, it seems
205
better to define a single name space for all options if only to avoid
206
ambiguities.
195
207
196
208
Using a name space is meant to help:
197
209
242
254
243
255
This also ensures compatibility with values provided via environment
244
256
variables or from the command line (where no validation can be expected
245
either)(done in the new design, some cases missing, see http://pad.lv/832064).
257
either)(done in the new design).
246
258
247
259
248
260
Option expansion
Loggerhead is a web-based interface for Breezy
Version: 2.0.1