/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/configuration.txt

  • Committer: Jelmer Vernooij
  • Date: 2011-12-24 10:10:59 UTC
  • mfrom: (6405 +trunk)
  • mto: This revision was merged to the branch mainline in revision 6407.
  • Revision ID: jelmer@samba.org-20111224101059-epghsc5y61hsgbl2
Merge bzr.dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
128
128
Adding a new store
129
129
------------------
130
130
 
131
 
 
132
 
 
133
131
The following stores are used by ``bzr`` in ways that illustrate various
134
132
uses of sections.
135
133
 
207
205
 
208
206
The value of an option is a unicode string or ``None`` if it's not
209
207
defined. By using ``from_unicode`` you can turn this string into a more
210
 
appropriate representation (a list of unicode strings for example).
 
208
appropriate representation.
 
209
 
 
210
If you need a list value, you should use ``ListOption`` instead.
 
211
 
211
212
 
212
213
Sections
213
214
--------
251
252
places to inherit from the existing basic tests and add their own specific
252
253
ones.
253
254
 
 
255
A ``Store`` defines how option values are stored, this includes:
 
256
 
 
257
* defining the sections where the options are grouped,
 
258
 
 
259
* defining how the values are quoted/unquoted for storage purposes. Stacks
 
260
  use the unquoted values internally (default value handling and option
 
261
  expansion are simpler this way) and ``bzr config`` quote them when they
 
262
  need to be displayed.
 
263
 
 
264
 
254
265
Filtering sections
255
266
------------------
256
267
 
327
338
``Stores`` can be used to build them but shouldn't be used otherwise, ditto
328
339
for sections. Again, the associated tests could and should be used against the
329
340
created stacks.
 
341
 
 
342
Also note that ``MemoryStack`` can be used without any disk resources which
 
343
allows for simpler and faster tests. A common pattern is to accept a
 
344
``config`` parameter related to a given feature and test it with predefined
 
345
configurations without involving the whole
 
346
stack. ``bzrlib.tests.test_commit``, ``bzrlib.tests.test_gpg`` and
 
347
``bzrlib.tests.test_smtp_connection`` are good examples.
 
348