~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Jelmer Vernooij
  • Date: 2016-04-03 16:32:31 UTC
  • mto: This revision was merged to the branch mainline in revision 6617.
  • Revision ID: jelmer@jelmer.uk-20160403163231-h72bo0uyek2gikw0
Don't put French text in doc/en/user-reference when LANGUAGE=fr_CH.UTF_8.

Show diffs side-by-side

added added

removed removed

Lines of Context:
14
14
 
15
15
  "John Doe <jdoe@example.com>"
16
16
 
17
 
See also the ``email`` configuration value.
 
17
See also the ``email`` configuration option.
18
18
 
19
19
BZR_PROGRESS_BAR
20
20
~~~~~~~~~~~~~~~~
54
54
 
55
55
Path to the Bazaar executable to use when using the bzr+ssh protocol.
56
56
 
57
 
See also the ``bzr_remote_path`` configuration value.
 
57
See also the ``bzr_remote_path`` configuration option.
58
58
 
59
59
BZR_EDITOR
60
60
~~~~~~~~~~
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
 
    check_signatures = require
 
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
Another such option is ``branchname``, which refers to the name of a colocated
 
337
branch.  For non-colocated branches, it behaves like basename.  It can be used
 
338
like this::
 
339
 
 
340
  [/home/vila/src/bzr/bugs]
 
341
  mypush = lp:~vila/bzr/{branchname}
 
342
 
 
343
When used with a colocated branch named ``832013-expand-in-stack``, we'll get::
 
344
 
 
345
  bzr config mypush
 
346
  lp:~vila/bzr/832013-expand-in-stack
 
347
 
 
348
When an option is local to a Section, it cannot be referred to from option
 
349
values in any other section from the same ``Store`` nor from any other
 
350
``Store``.
 
351
 
300
352
 
301
353
The main configuration file, bazaar.conf
302
354
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
311
363
    [DEFAULT]
312
364
    email             = John Doe <jdoe@isp.com>
313
365
    editor            = /usr/bin/vim
314
 
    check_signatures  = check-available
315
366
    create_signatures = when-required
316
367
 
317
368
 
329
380
 
330
381
    [http://hypothetical.site.com/branches/devel-branch]
331
382
    create_signatures = always
332
 
    check_signatures  = always
333
 
 
334
 
    [http://example.com/bzr/*]
335
 
    check_signatures  = require
336
383
 
337
384
The authentication configuration file, authentication.conf
338
385
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
342
389
of bzr that requires authentication (smtp for example).
343
390
 
344
391
The syntax of the file obeys the same rules as the others except for the
345
 
variable policies which don't apply.
 
392
option policies which don't apply.
346
393
 
347
394
For more information on the possible uses of the authentication configuration
348
395
file see :doc:`authentication-help`.
349
396
 
350
397
 
351
 
Common variable options
352
 
-----------------------
 
398
Common options
 
399
--------------
353
400
 
354
401
debug_flags
355
402
~~~~~~~~~~~
360
407
 
361
408
    debug_flags = hpss
362
409
 
 
410
or::
 
411
 
 
412
    debug_flags = hpss,evil
 
413
 
363
414
email
364
415
~~~~~
365
416
 
427
478
OS buffers to physical disk.  This is somewhat slower, but means data
428
479
should not be lost if the machine crashes.  See also repository.fdatasync.
429
480
 
 
481
gpg_signing_key
 
482
~~~~~~~~~~~~~~~
 
483
 
 
484
The GnuPG user identity to use when signing commits.  Can be an e-mail
 
485
address, key fingerprint or full key ID.  When unset or when set to
 
486
"default" Bazaar will use the user e-mail set with ``whoami``.
 
487
 
430
488
recurse
431
489
~~~~~~~
432
490
 
448
506
 
449
507
    gpg_signing_command = /usr/bin/gnpg
450
508
 
 
509
The specified command must accept the options "--clearsign" and "-u <email>".
 
510
 
451
511
bzr_remote_path
452
512
~~~~~~~~~~~~~~~
453
513
 
620
680
If present, defines the ``--strict`` option default value for checking
621
681
uncommitted changes before sending a merge directive.
622
682
 
 
683
add.maximum_file_size
 
684
~~~~~~~~~~~~~~~~~~~~~
 
685
 
 
686
Defines the maximum file size the command line "add" operation will allow
 
687
in recursive mode, with files larger than this value being skipped. You may 
 
688
specify this value as an integer (in which case it is interpreted as bytes), 
 
689
or you may specify the value using SI units, i.e. 10KB, 20MB, 1G. A value of 0 
 
690
will disable skipping.
623
691
 
624
692
External Merge Tools
625
693
--------------------
645
713
 
646
714
  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
647
715
 
 
716
Because ``mergetool`` and ``config`` itself both use curly braces as
 
717
interpolation markers, trying to display the mergetool line results in the
 
718
following problem::
 
719
 
 
720
 
 
721
  $ bzr config bzr.mergetool.kdiff3='kdiff3 {base} {this} {other} -o {result}'
 
722
  $ bzr config bzr.mergetool.kdiff3
 
723
  bzr: ERROR: Option base is not defined while expanding "kdiff3 {base} {this} {other} -o {result}".
 
724
 
 
725
To avoid this, ``config`` can be instructed not to try expanding variables::
 
726
 
 
727
  $ bzr config --all bzr.mergetool.kdiff3
 
728
  branch:
 
729
    bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
 
730
 
 
731
 
648
732
bzr.default_mergetool
649
733
~~~~~~~~~~~~~~~~~~~~~
650
734