1
================================
2
Simplifying Bazaar Configuration
3
================================
8
Not all needs can be addressed by the default values used inside bzr and
9
bzrlib, no matter how well they are chosen (and they are ;).
11
Options that are rarely used don't deserve a corresponding command line
12
switch in one or several commands.
14
Many parts of ``bzrlib`` depends on some constants though and the user
15
should be able to customize the behavior to suit his needs so these
16
constants need to become configuration options or more generally, be easier
19
These options can be set from the command-line, acquired from an environment
20
variable or recorded in a configuration file.
22
To simplify writing (and reading), this document refers to the old and new
24
* the old design is using ``Config`` as a base class for all config files,
25
* the new design use ``ConfigStacks`` of ``Section`` from config ``Stores``.
31
* Many parts of ``bzrlib`` declare constants and there is no way for the
32
user to look at or modify them (see http://pad.lv/832061).
34
* The old design requires a configuration object to create, modify or delete
35
a configuration option in a given configuration file. ``bzr config``
36
makes it almost transparent for the user. Internally though, not all cases
37
are handled: only BranchConfig implements chained configs, nothing is
38
provided at the repository level and too many plugins define their own
39
section or even their own config file. (config.Stack now provides a way to
40
chain config files, BranchStack properly implements the desired behavior,
41
``bzr config`` uses the new design).
43
* ``locations.conf`` defines the options that need to override any setting
44
in ``branch.conf`` for both local and remotes branches (but some remote
45
branch options just ignore ``locations.conf``). Many users want a way to
46
define default values for options that are not defined in ``branch.conf``
47
(and even more users think that ``locations.conf`` provide default values,
48
see also http://pad.lv/843211 and http://pad.lv/832046). This could be
49
approximated today by *not* defining these options in ``branch.conf`` but
50
in ``locations.conf`` instead. This workaround doesn't allow a user to
51
define defaults in ``locations.conf`` and override them in
52
``branch.conf``. (Allowing sections in 'bazaar.conf' (or introducing a new
53
defaults.conf' allowing sections) can now address that. Defining and using
54
a new file is easier as it avoids handling a migration path for
55
bazaar.conf and doesn't require banning the use of sections for special
56
purpose needs (ALIASES and BOOKMARKS for example)).
58
* Defining a new option requires adding a new method in the ``Config``
59
object to get access to features like:
61
* should the option be inherited by more specific sections, (this was more
62
or less the default in the old design, it is addressed by section
63
matchers in the new one by letting users define options in whatever
64
relevant section and let the matcher select the right ones).
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),
69
* the default value (including calling any python code that may be
70
required to calculate this value)(see http://pad.lv/832064, fixed),
72
* priority between sections in various config files (this is defined by
73
the section matcher associated with a given config store for stacks,
74
http://pad.lv/832046 is about adding a section matcher with clearer
75
semantics than the one used for locations.conf).
77
A related problem is that, in the actual implementation, some
78
configuration options have defined methods, others don't and this is
79
inconsistent. (Using only Stacks addresses that).
81
* Access to the 'active' configuration option value from the command line
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).
89
* Rules for configuration options are not clearly defined for remote
90
branches (they may differ between dumb and smart servers the former will
91
use the local ``bazaar.conf`` and ``locations.conf`` files while the later
92
will use (or ignore ?) the remote ones).
94
* The features offered by the Bazaar configuration files should be easily
95
accessible to plugin authors either by supporting plugin configuration
96
options in the configuration files or allowing the plugins to define their
97
own configuration files. (Separating Section, Store and Stack starts
98
addressing that, a stack registry should complete the needed means
99
http://pad.lv/832036).
101
* While the actual configuration files support sections, they are used in
102
mutually exclusive ways that make it impossible to offer the same set of
103
features to all configuration files:
105
* ``bazaar.conf`` use arbitrary names for sections. ``DEFAULT`` is used
106
for global options, ``ALIASES`` are used to define command aliases,
107
plugins can define their own sections, some plugins do that
108
(``bzr-bookmarks`` use ``BOOKMARKS`` for example), some other define
109
their own sections (this is addressed with the new design by using only
110
the ``DEFAULT`` section and ignore the others. When needed, one can
111
create a specific stack to get access to a specific section).
113
* ``locations.conf`` use globs as section names. This provides an easy
114
way to associate a set of options to a matching working tree or
115
branch, including remote ones.
117
* ``branch.conf`` doesn't use any section.
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``.
123
* There is no easy way to get configuration options for a given repository
124
or an arbitrary path. Working trees and branches are generally organized
125
in hierarchies and being able to share the option definitions is an often
126
required feature. This can also address some needs exhibited by various
127
branch schemes like looms, pipeline, colocated branches and nested
128
trees. Being able to specify options *in* a working tree could also help
129
support conflict resolution options for a given file, directory or
130
subtree (see http://pad.lv/359320).
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
145
globs. That may leave a glob and a path of equal length in a gray area but
146
in practice using ``bzr config`` should give enough feedback to address
147
them. See also http://pad.lv/832046 asking for a less magical section
150
* Internally, configuration files (and their fallbacks, ``bazaar.conf`` and
151
``locations.conf`` for ``branch.conf``) are read every time *one* option is
152
queried. Likewise, setting or deleting a configuration option implies
153
writing the configuration file *immediately* after re-reading the file to
154
avoid racing updates (see http://pad.lv/832042).
156
* The current implementation use a mix of transport-based and direct file
157
systems operations (Addressed by Store implementation relying on
158
transports only and the hpss implementing the corresponding verbs).
160
* While the underlying ``ConfigObj`` implementation provides an
161
interpolation feature, the ``bzrlib`` implementation doesn't provide an
162
easy handling of templates where other configuration options can be
163
interpolated. Instead, ``locations.conf`` (and only it) allows for
164
``appendpath`` and ``norecurse``. (Cross-section, cross-file interpolation
165
and section local options are now implemented in the new design).
167
* Inherited list values can't be modified, a more specific configuration can
168
only redefine the whole list.
170
* There is no easy way to define dicts (the most obvious one being to use a
171
dedicated section which is already overloaded). Using embedded sections
172
for this would not be practical either if we keep using a no-name section
173
for default values. In a few known cases, a bencoded dict is stored in a
174
config value, so while this isn't user-friendly, not providing a better
175
alternative shouldn't be a concern. A possible, limited, implementation
176
can be envisioned: limiting the dict to a single level only, with simple
177
names as keys and unicode strings as values. The keys can then be mapped
178
to options prefixed with the dict name.
181
Proposed implementation
182
=======================
185
Configuration files definition
186
------------------------------
188
While of course configurations files can be versioned they are not intended
189
to be accessed in sync with the files they refer to (one can imagine
190
handling versioned properties this way but this is *not* what the bazaar
191
configuration files are targeted at). ``bzr`` will always refer to
192
configuration files as they exist on disk when an option is queried or set.
194
The configuration files are generally local to the file system but some of
195
them can be accessed remotely (``branch.conf``, ``repo.conf``).
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
208
Using a name space is meant to help:
210
* avoid collisions between bzr and plugins and between plugins,
212
* discover the available options and making them easier to remember,
214
* organise the documentation for the option set.
216
Using valid python identifiers is recommended but not enforced (but we may
217
do so in the future).
219
The option name space is organized by topic:
221
* bzrlib options are grouped by topic (``branch``, ``tree``, ``repo``)
223
* plugins are encouraged (but not required) to prefix their specific options
224
with their name (``qbzr.`` for qbzr)
226
* collisions are detected at registration time so users are protected from
227
incompatibilities between plugins,
229
* options that need to be used by several plugins (or shared between ``bzr``
230
core and plugins) should be discussed but these discussions are already
231
happening so the risk of misuse is low enough.
236
All option values are text. They are provided as Unicode strings to API
237
users with some refinements:
239
* boolean values can be obtained for a set of acceptable strings (yes/no,
240
y/n, on/off, etc), (implemented with the ``from_unicode`` parameter)
242
* a list of strings from a value containing a comma separated list of
245
Since the configuration files can be edited by the user, ``bzr`` doesn't
246
expect their content to be valid at all times. Instead, the code using
247
options should be ready to handle *invalid* values by warning the user and
248
falling back to a default value.
250
Likely, if an option is not defined in any configuration file, the code
251
should fallback to a default value (helpers should be provided by the API to
252
handle common cases: warning the user, getting a particular type of value,
253
returning a default value)(most of that is now handled at Option definition).
255
This also ensures compatibility with values provided via environment
256
variables or from the command line (where no validation can be expected
257
either)(done in the new design).
263
Some option values can be templates and contain references to other
264
options. This is especially useful to define URLs in sections shared for
265
multiple branches for example. It can also be used to describe commands
266
where some parameters are set by ``bzrlib`` at runtime.
268
Since option values are text-only, and to avoid clashing with other option
269
expansion (also known as interpolation) syntaxes, references are enclosed
270
with curly brackets::
272
push_location = lp:~{launchpad_username}/bzr/{nick}
274
In the example above, ``launchpad_username`` is an already defined
275
configuration option while ``nick`` is the branch nickname and is set when a
276
configuration applies to a given branch.
278
The interpolation implementation should accept an additional dict so that
279
``bzrlib`` or plugins can define references that can be expanded without
280
being existing configuration options::
282
diff_command={cmd} {cmd_opts} {file_a} {file_b}
284
There are two common errors that should be handled when handling interpolation:
286
* loops: when a configuration value refers to itself, directly or indirectly,
288
* undefined references: when a configuration value refers to an unknown option.
290
The loop handling can be modified to allow cross-sections and cross-files
291
interpolation: if an option refers to itself (directly or indirectly) during
292
an expansion, the fallback sections or files can be queried for its value.
294
This allows list values to refer to the definition in the less specific
300
branch.conf for mybranch:
301
debug_flags = {debug_flags}, hpssdetail
303
$ bzr -d mybranch config debug_flags
306
Undefined references are detected if they are not defined in any
307
configuration. This will trigger errors while displaying the value. Diagnosing
308
typos should be doable in this case.
310
Configuration file syntax
311
-------------------------
313
The configuration file is mostly an ``ini-file``. It contains ``name = value``
314
lines grouped in sections. A section starts with a string enclosed in squared
315
brackets ('[section_name]`), this string uniquely identifies the section in
316
the file. Comments are allowed by prefixing them with the '#' character.
318
A section is named by the path (or some other unuique identifier) it should
319
apply to (more examples below).
321
When sections are used, they provide a finer grain of configuration by
322
defining option sets that apply to some working trees, branches,
323
repositories (or any kind of context) or part of them. The relationship
324
between a given context and the sections it applies to is defined by the
327
So far, Bazaar uses a glob in ``locations.conf`` and select the sections
328
that apply to a given url (or a local path).
330
The subset is defined by the common leading path or a glob.
332
Different kinds of section names can be defined:
334
* a full url: used to described options for remote branches and
335
repositories (LocationMatcher supports this).
337
* local absolute path: used for working trees, branches or repositories
338
on the local disks (LocationMatcher supports this).
340
* relative path: the path is relative to the configuration file and can be
341
used for colocated branches or threads in a loom, i.e any working tree,
342
branch or repository that is located in a place related to the
343
configuration file path. Some configuration files may define this path
344
relationship in specific ways to make them easier to use (i.e. if a config
345
file is somewhere below ``.bzr`` and refers to threads in a loom for
346
example, the relative path would be the thread name, it doesn't have to be
347
an *exact* relative path, as long as its interpretation is unambiguous and
348
clear for the user) (No section matchers support this so far, needs to
354
Section names define another name space (than the option names one) with an
355
entirely different purpose: in a given configuration file, for a given
356
context, only some sections will be relevant and will be queried in a
359
This matching is specific to each config file and implemented by the
360
SectionMatcher objects.
362
Whatever this matching does, the user can observe the results with the ``bzr
363
config`` command which displays the sections in the order they are queried.
368
The context here is either:
374
Note that for both the provided context and the section names, if an URL uses
375
a ``file:///`` form, it is converted to a local path.
377
The sections names can use globs for each path component
378
(i.e. ``/dir/*/subdir`` is allowed but ``/dir/\*\*/subdir`` will match
379
``/dir/a/subdir`` but not ``/dir/a/b/subdir``.
381
The reason is that the ordering is defined by sorting the section names
382
matching the context on the number of path components followed by the path
383
itself in lexicographical order. This results in most specific sections being
384
queried before the more generic ones.
389
``LocationMatcher`` has some obscure (for unaware users) edge cases and
390
limitations that can be surprising. ``PathMatcher`` aims at addressing these
391
issues by providing simpler rules while still giving full control to the
392
user (http://pad.lv/832046).
394
The context here is a local path, absolute or relative. If the path is
395
relative it is interpreted from the file base directory.
397
Note that 'base directory' for configuration files in Bazaar directories is
400
* the home directory for files under ``~/.bazaar``,
402
* the ``.bzr`` base directory for files under ``.bzr``.
404
The order is the one observed in the file so most generic values are specified
405
first and most specific ones last. As such, the order in the file is the
406
opposite of the one displayed by ``bzr config`` which displays most specific
407
values first. This seems to be the most natural order in both cases.
409
A section matches if the section name is a prefix of the context path
410
(relative paths being converted to absolute on the fly).
415
(copied from a recent version of bzr.dev for easier reading, refer to the
416
original for an up to date version)
418
The Option object is used to define its properties:
420
* name: a name: a valid python identifier (even if it's not used as an
421
identifier in python itself). This is also used to register the option.
423
* default: the default value that Stack.get() should return if no
424
value can be found for the option.
426
* default_from_env: a list of environment variables. The first variable set
427
will provide a default value overriding 'default' which remains the
428
default value if *no* environment variable is set.
430
* help: a doc string describing the option, the first line should be a
431
summary and can be followed by a blank line and a more detailed
434
* from_unicode: a callable accepting a unicode string and returning a
435
suitable value for the option. If the string cannot be coerced it should
438
* invalid: the action to be taken when an invalid value is encountered in a
439
store (during a Stack.get()).
444
Options are grouped into sections which share some properties with the well
447
* the key is the name,
448
* you can get, set and remove an option,
449
* the value is a unicode string.
451
MutableSection is needed to set or remove an option, ReadOnlySection should
457
This is an implementation-level object that should rarely be used directly.
459
* it can be local or remote
463
All lock operations should be implemented via transport objects. (True for
468
Working trees, branches and repositories should define a config attribute
469
following the same life cycle as their lock: the associated config file is
470
read once and written once if needed. This should minimize the file system
471
accesses or the network requests. There is no known racing scenarios for
472
configuration options, changing the existing implementation to this less
473
constrained one shouldn't introduce any. Yet, in order to detect such
474
racing scenarios, we can add a check that the current content of the
475
configuration file is the expected one before writing the new content and
476
emit warnings if differences occur. The checks should be performed for the
477
modified values only. As of today (and in the foreseeable future), the
478
size of the configuration files are small enough to be kept in memory (see
479
http://pad.lv/832042).
484
This the object that provides access to the needed features:
486
* getting an option value,
488
* setting an option value,
490
* deleting an option value,
492
* handling a list of configuration files and for each of them a section
493
matcher providing the sections that should be tried in the given order to
496
* handling a Store and a section where option creation, modification and
499
Depending on the files involved, a working tree, branch or repository object
500
(or more generally a context) should be provided to access the corresponding
501
configuration files. Note that providing a working tree object also
502
implicitly provides the associated branch and repository object so only one
503
of them is required (or none for configuration files specific to the user
504
like ``bazaar.conf``).
506
Getting an option value
507
~~~~~~~~~~~~~~~~~~~~~~~
509
Depending on the option, there are various places where it can be defined
510
and several ways to override these settings when needed.
512
The following lists all possible places where a configuration option can
513
be defined, but some options will make sense in only some of them. The
514
first to define a value for an option wins (None is therefore used to
515
express that an option is not set).
518
``-Ooption=value`` see http://pad.lv/491196.
520
* ``~/.bazaar/locations.conf``
522
When an option is set in ``locations.conf`` it overrides any other
523
configuration file. This should be used with care as it allows setting a
524
different value than what is recommended by the project
526
* ``tree`` (Not Implemented Yet)
528
The options related to the working tree.
530
This includes all options related to commits, ignored files, junk files,
533
Note that the sections defined there can use relative paths if some
534
options should apply to a subtree or some specific files only.
536
See http://pad.lv/430538 and http://pad.lv/654998.
538
* ``branch`` located in ``.bzr/branch/branch.conf``
540
The options related to the branch.
542
Sections can be defined for colocated branches or loom threads.
544
* ``repository`` (Not Implemented Yet)
546
The options related to the repository.
548
Using an option to describe whether or not a repository is shared could
549
help address http://pad.lv/342119 but this will probably requires a format
552
* ``project`` (Not Implemented Yet)
554
The options common to all branches and working trees for a project.
556
* ``organization`` (Not Implemented Yet)
558
The options common to all branches and working trees for an organization.
560
See http://pad.lv/419854.
562
* ``system`` (Not Implemented Yet but see http://pad.lv/419854 and
563
https://code.launchpad.net/~thomir/bzr/add-global-config/+merge/69592)
565
The options common to all users of a system (may be /etc/bzr/defaults
566
or /usr/local/etc/bzr/defaults or
567
/Library/Preferences/com.canonical.defaults or c:\windows\bazaar.conf
568
(someone fix this one please ;) depending on the OS).
572
The options the user has selected for the host he is using.
574
Sections can be defined for both remote and local branches to define
575
default values (i.e. the most common use of ``locations.conf`` today).
577
* default (implemented by the OptionRegistry)
579
The options defined in the ``bzr`` source code.
581
This will be implemented via the Option objects.
583
Plugins can define additional configuration files as they see fit and
584
insert them in this list, see their documentation for details.
589
There are ways to keep the same files while ensuring compatibility via various
590
tricks but there are cases where using new files to replace the old ones is
593
* no need to ensure that the new files are correctly handled by old bzr
596
* making it clear for users that there is a switch and let them migrate at
599
The known cases so far are described below.
601
Obvious at this point:
603
* Branch provides ``get_config`` for the old design and ``get_config_stack``
604
for the new design so that both designs are supported. Once the store
605
sharing is implemented, we may want to use an attribute for the stack and
606
deprecate both ``get_config`` and ``get_config_stack``.
608
* Sections names in ``bazaar.conf`` are arbitrary (except ``DEFAULT``) so
609
it's easier to leave the file untouched and let plugin authors and users
610
migrate away (or not) from them. For ``bzr`` itself, that means
611
``DEFAULT`` is the only section used for most of the options and provides
612
user defaults. ``ALIASES`` requires a specific stack but only the ``bzr
613
alias`` command cares about that.
615
* Option policies should be deprecated:
617
* The ``norecurse`` policy is useless, all options are recursive by
618
default. If specific values are needed for specific paths, they can just
619
be defined as such (in the appropriate sections or files).
621
* The ``appendpath`` policy should be implemented via interpolation and a
622
``relpath`` option provided by the configuration framework
623
(http://pad.lv/832013).
625
* Section order in ``locations.conf`` has issues which make a migration to a
626
different way to organize the sections (hence the file content) far easier
629
* ``locations.conf`` is really for overrides but many users have been using it
630
to provide defaults. There is no way to know if the whole content has been
631
used for defaults or overrides or a mix of both. So there is no way to
632
migrate this automatically.
634
Unclear at this point:
636
* [BOOKMARKS] section can be replaced by ``bookmarks.xxx`` options (the
637
bookmarks plugins already uses ``bookmarks_xxx`` in branch.conf since no
638
sections were supported there). The easiest here is probably to just merge
639
the plugin into core and use the appropriate option names consistently. A
640
``config:`` directory service may even be better as any option can be used
641
as a bookmark. This allows things like::
644
my_push = lp:<launchpad.login>/xxx/{nick}
645
web_site=ftp://example.com/
647
bzr push config:web_site
649
Which means we completely replace the plugin and don't need to care about
650
migrating the section.
652
* [ALIASES] section can be replaced by corresponding bzr.alias.xxx
653
options. This could be automated by creating the corresponding options ?
655
* I don't know about other sections, feedback welcome. Plugin authors are
656
encouraged to migrate to the new name space scheme by prefixing their
657
options with their plugin name.
662
These are random notes about concepts, ideas or issues not implemented yet.
664
Developer facing concepts
665
-------------------------
670
* list of allowed Config IDs (this allows a list of possible config files in
671
bazaar.conf only option and use it while bootstrapping the config
674
* blacklist of config IDs (some options *can't* be stored (modified) by the
677
An alternative is to just let the devs decide which stack they use for a
678
given option, ``stacked_on_location`` for example is said to relate to the
679
branch only and changing it or setting it in a different config file may not
680
be appropriate. This may not be a good example as there is also the
681
``default_stack_on`` option which can be set only in ``control.conf``
687
* a lazy cache for the option values (should be reset on modifications as
688
interpolations will make it tricky to update incrementally) (see FIXME in
689
config.py Stack.get()))
691
* ensures that the Stores involved generate as less IOs as possible (see
692
http://pad.lv/832042)
694
* ensures that the transaction is the object life time (i.e. modifications
695
will be taken into account *iff* they are committed explicitly).
700
* ensures that a config ID is a unique identifier
706
* ensures that the transaction is the object life time (i.e. modifications
707
will be taken into account *iff* they are committed explicitly).
715
* ConfigObj (bazaar.conf)
717
* DB (<scheme>://bazaar.launchpad.net/bazaar.conf)
720
Why and when locking config files matter
721
----------------------------------------
723
This is relevant for http://pad.lv/832042.
725
``bzr`` behavior, as well as the objects it acts upon, is configured via a
726
set of so-called configuration files.
728
These files allow to define working trees, branches and repositories, their
729
relationships and how ``bzr`` should handle them.
731
The default behavior of ``bzr`` is aimed at making this configuration as
732
transparent as possible by keeping track of how these objects are created
733
and modified when they are used. In short, they are useless until you want
734
to change the default behavior in some specific context.
736
We mostly **read** config options. Therefore all we care about is to
739
* we get a valid config file at all times when reading,
741
* we always leave a valid config file when writing (via the rename dance)
743
From there, conceptually, all operations can clearly define whether or not
744
they need to modify a config file and do so only when they succeed. All
745
modifications occurring during such an operation are delayed until the very
746
end of the operation.
748
Now, we want to minimize the overlapping times where one bzr operation has
749
changed a value and another concurrent operation is unaware of this
752
These overlapping periods are *as of today* rare.
754
The only known case, http://pad.lv/525571 has been fixed in bzr-2.1.3. The
755
bug there was triggered when two processes tried to write the same config
756
file at the same time leaving an invalid file in the end.
758
Such a period can be recognized and detected though: when changing an option
759
value, if the preserved original value is different in the config file,
760
someone else modified it and the operation can be invalid because it relied
761
on the original value.
763
For the sake of the example, if an option value represent a global unique ID
764
via a simple counter (very bad idea), if two operations try to increment it,
765
both will use the same value that won't be unique anymore. Checking the
766
value present in the file when trying to save the updated value with
767
identify such a collision.
769
An assumption is floating around: it should be enough to report when an
770
operation is modifying an already modified option and observe that no-one
771
reports such occurrences.
773
Note that this assumption is made in a context where *no* known scenarios
774
exist in the bzr code base not in any plugin (for a best effort value of
775
'any', feedback highly welcome, bug reports even ;)
777
With this in mind, we can change the definition of config options, stores
778
and stacks to ensure that:
780
* a config file is read only once when in read access,
782
* a config file is read only once and written only once when in write
783
access, adding the check mentioned above will require *one* additional
786
A reader can then safely assume that reading a config file gives it a valid
787
(and coherent) definition of the configuration when the operation
788
starts. All the operation has to do is to declare which config files may be
789
modified by an operation (whether or not we can be liberal on this 'may be'
790
is yet to be defined).
added
removed
doc/developers/new-config-rationale.txt
