← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/help_topics/en/configuration.txt

  • Committer: Launchpad Translations on behalf of bzr-core
  • Date: 2012-07-21 04:30:31 UTC
  • mto: (6581.1.1 trunk)
  • mto: This revision was merged to the branch mainline in revision 6582.
  • Revision ID: launchpad_translations_on_behalf_of_bzr-core-20120721043031-pjhomz88j0qw381z
Launchpad automatic translations update.

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/help_topics/en/configuration.txt
221
221
~~~~~~~~~~~~~~
222
222
 
223
223
An ini file has three types of contructs: section headers, section
224
 
variables and comments.
 
224
options and comments.
225
225
 
226
226
Comments
227
227
^^^^^^^^
240
240
 
241
241
The only valid section headers for bazaar.conf currently are [DEFAULT] and
242
242
[ALIASES].  Section headers are case sensitive. The default section provides for
243
 
setting variables which can be overridden with the branch config file.
 
243
setting options which can be overridden with the branch config file.
244
244
 
245
 
For ``locations.conf``, the variables from the section with the
 
245
For ``locations.conf``, the options from the section with the
246
246
longest matching section header are used to the exclusion of other
247
247
potentially valid section headers. A section header uses the path for
248
248
the branch as the section header. Some examples include::
251
251
    [/home/jdoe/branches/]
252
252
 
253
253
 
254
 
Section variables
255
 
^^^^^^^^^^^^^^^^^
 
254
Section options
 
255
^^^^^^^^^^^^^^^
256
256
 
257
 
A section variable resides within a section. A section variable contains a
258
 
variable name, an equals sign and a value.  For example::
 
257
A section option resides within a section. A section option contains an
 
258
option name, an equals sign and a value.  For example::
259
259
 
260
260
    email            = John Doe <jdoe@isp.com>
261
261
    gpg_signing_key  = Amy Pond <amy@example.com>
262
262
 
263
 
A variable can reference other variables **in the same configuration file** by
264
 
enclosing them in curly brackets::
 
263
A option can reference other options by enclosing them in curly brackets::
265
264
 
266
265
    my_branch_name = feature_x
267
266
    my_server      = bzr+ssh://example.com
268
267
    push_location   = {my_server}/project/{my_branch_name}
269
268
 
270
 
 
271
 
Variable policies
272
 
^^^^^^^^^^^^^^^^^
273
 
 
274
 
Variables defined in a section affect the named directory or URL plus
275
 
any locations they contain.  Policies can be used to change how a
276
 
variable value is interpreted for contained locations.  Currently
 
269
Option policies
 
270
^^^^^^^^^^^^^^^
 
271
 
 
272
Options defined in a section affect the named directory or URL plus
 
273
any locations they contain.  Policies can be used to change how an
 
274
option value is interpreted for contained locations.  Currently
277
275
there are three policies available:
278
276
 
279
277
 none:
286
284
   for contained locations, any additional path components are
287
285
   appended to the value.
288
286
 
289
 
Policies are specified by keys with names of the form "$var:policy".
 
287
Policies are specified by keys with names of the form "<option_name>:policy".
290
288
For example, to define the push location for a tree of branches, the
291
289
following could be used::
292
290
 
297
295
With this configuration, the push location for ``/top/location/branch1``
298
296
would be ``sftp://example.com/location/branch1``.
299
297
 
 
298
Section local options
 
299
^^^^^^^^^^^^^^^^^^^^^
 
300
 
 
301
Some options are defined automatically inside a given section and can be
 
302
refered to in this section only. 
 
303
 
 
304
For example, the ``appendpath`` policy can be used like this::
 
305
 
 
306
  [/home/vila/src/bzr/bugs]
 
307
  mypush = lp:~vila/bzr
 
308
  mypush:policy=appendpath
 
309
 
 
310
Using ``relpath`` to achieve the same result is done like this::
 
311
 
 
312
  [/home/vila/src/bzr/bugs]
 
313
  mypush = lp:~vila/bzr/{relpath}
 
314
 
 
315
In both cases, when used in a directory like
 
316
``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
 
317
 
 
318
   $ bzr config mypush
 
319
   lp:~vila/bzr/832013-expand-in-stack
 
320
 
 
321
Another such option is ``basename`` which can be used like this::
 
322
 
 
323
  [/home/vila/src/bzr]
 
324
  mypush = lp:~vila/bzr/{basename}
 
325
 
 
326
When used in a directory like
 
327
``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
 
328
 
 
329
   $ bzr config mypush
 
330
   lp:~vila/bzr/832013-expand-in-stack
 
331
 
 
332
Note that ``basename`` here refers to the base name of ``relpath`` which
 
333
itself is defined as the relative path between the section name and the
 
334
location it matches.
 
335
 
 
336
When an option is local to a Section, it cannot be referred to from option
 
337
values in any other section from the same ``Store`` nor from any other
 
338
``Store``.
 
339
 
300
340
 
301
341
The main configuration file, bazaar.conf
302
342
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
337
377
of bzr that requires authentication (smtp for example).
338
378
 
339
379
The syntax of the file obeys the same rules as the others except for the
340
 
variable policies which don't apply.
 
380
option policies which don't apply.
341
381
 
342
382
For more information on the possible uses of the authentication configuration
343
383
file see :doc:`authentication-help`.
344
384
 
345
385
 
346
 
Common variable options
347
 
-----------------------
 
386
Common options
 
387
--------------
348
388
 
349
389
debug_flags
350
390
~~~~~~~~~~~