~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Patch Queue Manager
  • Date: 2016-04-21 04:10:52 UTC
  • mfrom: (6616.1.1 fix-en-user-guide)
  • Revision ID: pqm@pqm.ubuntu.com-20160421041052-clcye7ns1qcl2n7w
(richard-wilbur) Ensure build of English use guide always uses English text
 even when user's locale specifies a different language. (Jelmer Vernooij)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
====================
2
 
Bazaar configuration
3
 
====================
4
 
 
5
 
Information on how to configure Bazaar.
6
 
 
7
 
.. TODO: Should have some explanation of why you'd want things in
8
 
.. branch.conf.
9
 
 
10
 
 
11
 
Environment variables
12
 
=====================
 
1
Configuration Settings
 
2
=======================
 
3
 
 
4
Environment settings
 
5
---------------------
 
6
 
13
7
While most configuration is handled by configuration files, some options
14
8
which may be semi-permanent can also be controlled through the environment.
15
9
 
16
10
BZR_EMAIL
17
 
---------
 
11
~~~~~~~~~
 
12
 
18
13
Override the email id used by Bazaar.  Typical format::
19
14
 
20
15
  "John Doe <jdoe@example.com>"
21
16
 
22
 
See also the ``email`` configuration value.
 
17
See also the ``email`` configuration option.
23
18
 
24
19
BZR_PROGRESS_BAR
25
 
----------------
26
 
Override the progress display.  Possible values are "none", "dots", "tty"
 
20
~~~~~~~~~~~~~~~~
 
21
 
 
22
Override the progress display.  Possible values are "none" or "text".  If
 
23
the value is "none" then no progress bar is displayed.  The value "text" draws
 
24
the ordinary command line progress bar.
27
25
 
28
26
BZR_SIGQUIT_PDB
29
 
---------------
 
27
~~~~~~~~~~~~~~~
 
28
 
30
29
Control whether SIGQUIT behaves normally or invokes a breakin debugger.
31
 
0 = Standard SIGQUIT behavior
32
 
1 = Invoke breakin debugger (default)
 
30
 
 
31
* 0 = Standard SIGQUIT behavior (normally, exit with a core dump)
 
32
* 1 = Invoke breakin debugger (default)
33
33
 
34
34
BZR_HOME
35
 
--------
 
35
~~~~~~~~
 
36
 
36
37
Override the home directory used by Bazaar.
37
38
 
38
39
BZR_SSH
39
 
-------
 
40
~~~~~~~
 
41
 
40
42
Select a different SSH implementation.
41
43
 
42
44
BZR_PDB
43
 
-------
 
45
~~~~~~~
 
46
 
44
47
Control whether to launch a debugger on error.
45
 
0 = Standard behavior
46
 
1 = Launch debugger
 
48
 
 
49
* 0 = Standard behavior
 
50
* 1 = Launch debugger
47
51
 
48
52
BZR_REMOTE_PATH
49
 
---------------
 
53
~~~~~~~~~~~~~~~
 
54
 
50
55
Path to the Bazaar executable to use when using the bzr+ssh protocol.
51
56
 
52
 
See also the ``bzr_remote_path`` configuration value
 
57
See also the ``bzr_remote_path`` configuration option.
53
58
 
54
59
BZR_EDITOR
55
 
----------
 
60
~~~~~~~~~~
 
61
 
56
62
Path to the editor Bazaar should use for commit messages, etc.
57
63
 
 
64
BZR_LOG
 
65
~~~~~~~
 
66
 
 
67
Location of the Bazaar log file. You can check the current location by
 
68
running ``bzr version``.
 
69
 
 
70
The log file contains debug information that is useful for diagnosing or
 
71
reporting problems with Bazaar.
 
72
 
 
73
Setting this to ``NUL`` on Windows or ``/dev/null`` on other platforms
 
74
will disable logging.
 
75
 
 
76
 
58
77
BZR_PLUGIN_PATH
59
 
---------------
 
78
~~~~~~~~~~~~~~~
 
79
 
60
80
The path to the plugins directory that Bazaar should use.
 
81
If not set, Bazaar will search for plugins in:
 
82
 
 
83
* the user specific plugin directory (containing the ``user`` plugins),
 
84
 
 
85
* the bzrlib directory (containing the ``core`` plugins),
 
86
 
 
87
* the site specific plugin directory if applicable (containing
 
88
  the ``site`` plugins).
 
89
 
 
90
If ``BZR_PLUGIN_PATH`` is set in any fashion, it will change the
 
91
the way the plugin are searched. 
 
92
 
 
93
As for the ``PATH`` variables, if multiple directories are
 
94
specified in ``BZR_PLUGIN_PATH`` they should be separated by the
 
95
platform specific appropriate character (':' on Unix,
 
96
';' on windows)
 
97
 
 
98
By default if ``BZR_PLUGIN_PATH`` is set, it replaces searching
 
99
in ``user``.  However it will continue to search in ``core`` and
 
100
``site`` unless they are explicitly removed.
 
101
 
 
102
If you need to change the order or remove one of these
 
103
directories, you should use special values:
 
104
 
 
105
* ``-user``, ``-core``, ``-site`` will remove the corresponding
 
106
  path from the default values,
 
107
 
 
108
* ``+user``, ``+core``, ``+site`` will add the corresponding path
 
109
  before the remaining default values (and also remove it from
 
110
  the default values).
 
111
 
 
112
Note that the special values 'user', 'core' and 'site' should be
 
113
used literally, they will be substituted by the corresponding,
 
114
platform specific, values.
 
115
 
 
116
The examples below use ':' as the separator, windows users
 
117
should use ';'.
 
118
 
 
119
Overriding the default user plugin directory::
 
120
 
 
121
  BZR_PLUGIN_PATH='/path/to/my/other/plugins'
 
122
 
 
123
Disabling the site directory while retaining the user directory::
 
124
 
 
125
  BZR_PLUGIN_PATH='-site:+user'
 
126
 
 
127
Disabling all plugins (better achieved with --no-plugins)::
 
128
 
 
129
  BZR_PLUGIN_PATH='-user:-core:-site'
 
130
 
 
131
Overriding the default site plugin directory::
 
132
 
 
133
  BZR_PLUGIN_PATH='/path/to/my/site/plugins:-site':+user
 
134
 
 
135
BZR_DISABLE_PLUGINS
 
136
~~~~~~~~~~~~~~~~~~~
 
137
 
 
138
Under special circumstances (mostly when trying to diagnose a
 
139
bug), it's better to disable a plugin (or several) rather than
 
140
uninstalling them completely. Such plugins can be specified in
 
141
the ``BZR_DISABLE_PLUGINS`` environment variable.
 
142
 
 
143
In that case, ``bzr`` will stop loading the specified plugins and
 
144
will raise an import error if they are explicitly imported (by
 
145
another plugin that depends on them for example).
 
146
 
 
147
Disabling ``myplugin`` and ``yourplugin`` is achieved by::
 
148
 
 
149
  BZR_DISABLE_PLUGINS='myplugin:yourplugin'
 
150
 
 
151
BZR_PLUGINS_AT
 
152
~~~~~~~~~~~~~~
 
153
 
 
154
When adding a new feature or working on a bug in a plugin,
 
155
developers often need to use a specific version of a given
 
156
plugin. Since python requires that the directory containing the
 
157
code is named like the plugin itself this make it impossible to
 
158
use arbitrary directory names (using a two-level directory scheme
 
159
is inconvenient). ``BZR_PLUGINS_AT`` allows such directories even
 
160
if they don't appear in ``BZR_PLUGIN_PATH`` .
 
161
 
 
162
Plugins specified in this environment variable takes precedence
 
163
over the ones in ``BZR_PLUGIN_PATH``.
 
164
 
 
165
The variable specified a list of ``plugin_name@plugin path``,
 
166
``plugin_name`` being the name of the plugin as it appears in
 
167
python module paths, ``plugin_path`` being the path to the
 
168
directory containing the plugin code itself
 
169
(i.e. ``plugins/myplugin`` not ``plugins``).  Use ':' as the list
 
170
separator, use ';' on windows.
 
171
 
 
172
Example:
 
173
~~~~~~~~
 
174
 
 
175
Using a specific version of ``myplugin``:
 
176
``BZR_PLUGINS_AT='myplugin@/home/me/bugfixes/123456-myplugin``
61
177
 
62
178
BZRPATH
63
 
-------
 
179
~~~~~~~
 
180
 
64
181
The path where Bazaar should look for shell plugin external commands.
65
182
 
66
183
 
 
184
http_proxy, https_proxy
 
185
~~~~~~~~~~~~~~~~~~~~~~~
 
186
 
 
187
Specifies the network proxy for outgoing connections, for example::
 
188
 
 
189
  http_proxy=http://proxy.example.com:3128/ 
 
190
  https_proxy=http://proxy.example.com:3128/
 
191
 
 
192
 
67
193
Configuration files
68
 
===================
 
194
-------------------
69
195
 
70
196
Location
71
 
--------
72
 
 
73
 
Configuration files are located in ``$HOME/.bazaar`` and are
74
 
sometimes referred to as ``ini files``:
 
197
~~~~~~~~
 
198
 
 
199
Configuration files are located in ``$HOME/.bazaar`` on Unix and
 
200
``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
 
201
Windows. (You can check the location for your system by using
 
202
``bzr version``.)
 
203
 
 
204
There are three primary configuration files in this location:
75
205
 
76
206
* ``bazaar.conf`` describes default configuration options,
77
207
 
87
217
one of the values for a branch with a setting that is specific to you then you
88
218
can do so in ``locations.conf``.
89
219
 
90
 
General Format
91
 
--------------
 
220
General format
 
221
~~~~~~~~~~~~~~
92
222
 
93
223
An ini file has three types of contructs: section headers, section
94
 
variables and comments.
 
224
options and comments.
95
225
 
96
226
Comments
97
 
~~~~~~~~
 
227
^^^^^^^^
 
228
 
98
229
A comment is any line that starts with a "#" (sometimes called a "hash
99
230
mark", "pound sign" or "number sign"). Comment lines are ignored by
100
231
Bazaar when parsing ini files.
101
232
 
102
 
Section Headers
103
 
~~~~~~~~~~~~~~~
 
233
Section headers
 
234
^^^^^^^^^^^^^^^
 
235
 
104
236
A section header is a word enclosed in brackets that starts at the begining
105
237
of a line.  A typical section header looks like this::
106
238
 
107
239
    [DEFAULT]
108
240
 
109
 
The only valid section header for bazaar.conf is [DEFAULT], which is
110
 
case sensitive. The default section provides for setting variables
111
 
which can be overridden with the branch config file.
 
241
The only valid section headers for bazaar.conf currently are [DEFAULT] and
 
242
[ALIASES].  Section headers are case sensitive. The default section provides for
 
243
setting options which can be overridden with the branch config file.
112
244
 
113
 
For ``locations.conf``, the variables from the section with the
 
245
For ``locations.conf``, the options from the section with the
114
246
longest matching section header are used to the exclusion of other
115
247
potentially valid section headers. A section header uses the path for
116
248
the branch as the section header. Some examples include::
119
251
    [/home/jdoe/branches/]
120
252
 
121
253
 
122
 
Section Variables
123
 
~~~~~~~~~~~~~~~~~
 
254
Section options
 
255
^^^^^^^^^^^^^^^
124
256
 
125
 
A section variable resides within a section. A section variable contains a
126
 
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::
127
259
 
128
260
    email            = John Doe <jdoe@isp.com>
129
 
    check_signatures = require
130
 
 
131
 
 
132
 
Variable Policies
133
 
~~~~~~~~~~~~~~~~~
134
 
 
135
 
Variables defined in a section affect the named directory or URL plus
136
 
any locations they contain.  Policies can be used to change how a
137
 
variable value is interpreted for contained locations.  Currently
 
261
    gpg_signing_key  = Amy Pond <amy@example.com>
 
262
 
 
263
A option can reference other options by enclosing them in curly brackets::
 
264
 
 
265
    my_branch_name = feature_x
 
266
    my_server      = bzr+ssh://example.com
 
267
    push_location   = {my_server}/project/{my_branch_name}
 
268
 
 
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
138
275
there are three policies available:
139
276
 
140
277
 none:
147
284
   for contained locations, any additional path components are
148
285
   appended to the value.
149
286
 
150
 
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".
151
288
For example, to define the push location for a tree of branches, the
152
289
following could be used::
153
290
 
158
295
With this configuration, the push location for ``/top/location/branch1``
159
296
would be ``sftp://example.com/location/branch1``.
160
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
 
161
352
 
162
353
The main configuration file, bazaar.conf
163
 
----------------------------------------
 
354
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
164
355
 
165
 
The main configuration file, ``$HOME/.bazaar/bazaar.conf``, only allows one
166
 
section called ``[DEFAULT]``. This default section contains the default
 
356
``bazaar.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
 
357
The default section contains the default
167
358
configuration options for all branches. The default section can be
168
359
overriden by providing a branch-specific section in ``locations.conf``.
169
360
 
172
363
    [DEFAULT]
173
364
    email             = John Doe <jdoe@isp.com>
174
365
    editor            = /usr/bin/vim
175
 
    check_signatures  = check-available
176
366
    create_signatures = when-required
177
367
 
178
368
 
179
369
The branch location configuration file, locations.conf
180
 
------------------------------------------------------
 
370
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
181
371
 
182
 
``$HOME/.bazaar/locations.conf`` allows one to specify overriding settings for
 
372
``locations.conf`` allows one to specify overriding settings for
183
373
a specific branch. The format is almost identical to the default section in
184
374
bazaar.conf with one significant change: The section header, instead of saying
185
375
default, will be the path to a branch that you wish to override a value
190
380
 
191
381
    [http://hypothetical.site.com/branches/devel-branch]
192
382
    create_signatures = always
193
 
    check_signatures  = always
194
 
 
195
 
    [http://bazaar-vcs.org/bzr/*]
196
 
    check_signatures  = require
197
383
 
198
384
The authentication configuration file, authentication.conf
199
 
----------------------------------------------------------
 
385
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
200
386
 
201
 
``$HOME/.bazaar/authentication.conf`` allows one to specify credentials for
 
387
``authentication.conf`` allows one to specify credentials for
202
388
remote servers. This can be used for all the supported transports and any part
203
389
of bzr that requires authentication (smtp for example).
204
390
 
205
391
The syntax of the file obeys the same rules as the others except for the
206
 
variable policies which don't apply.
 
392
option policies which don't apply.
207
393
 
208
394
For more information on the possible uses of the authentication configuration
209
 
file see the `authentication configuration file documentation`_.
210
 
 
211
 
.. _authentication configuration file documentation: authentication_conf.html
212
 
 
213
 
Common Variable Options
214
 
=======================
 
395
file see :doc:`authentication-help`.
 
396
 
 
397
 
 
398
Common options
 
399
--------------
 
400
 
 
401
debug_flags
 
402
~~~~~~~~~~~
 
403
 
 
404
A comma-separated list of debugging options to turn on.  The same values
 
405
can be used as with the -D command-line option (see `help global-options`).
 
406
For example::
 
407
 
 
408
    debug_flags = hpss
 
409
 
 
410
or::
 
411
 
 
412
    debug_flags = hpss,evil
215
413
 
216
414
email
217
 
-----
 
415
~~~~~
 
416
 
218
417
The email address to use when committing a branch. Typically takes the form
219
418
of::
220
419
 
221
420
    email = Full Name <account@hostname.tld>
222
421
 
223
422
editor
224
 
------
 
423
~~~~~~
 
424
 
225
425
The path of the editor that you wish to use if *bzr commit* is run without
226
426
a commit message. This setting is trumped by the environment variable
227
 
``$BZR_EDITOR``, and overrides ``$VISUAL`` and ``$EDITOR``.
 
427
``BZR_EDITOR``, and overrides the ``VISUAL`` and ``EDITOR`` environment
 
428
variables.
 
429
 
 
430
log_format
 
431
~~~~~~~~~~
 
432
 
 
433
The default log format to use. Standard log formats are ``long``, ``short``
 
434
and ``line``. Additional formats may be provided by plugins. The default
 
435
value is ``long``.
228
436
 
229
437
check_signatures
230
 
----------------
231
 
Defines the behavior for signatures.
 
438
~~~~~~~~~~~~~~~~
 
439
 
 
440
Reserved for future use.  These options will allow a policy for branches to
 
441
require signatures.
232
442
 
233
443
require
234
444
    The gnupg signature for revisions must be present and must be valid.
242
452
    no signature is present.
243
453
 
244
454
create_signatures
245
 
-----------------
246
 
Defines the behaviour of signing revisions.
 
455
~~~~~~~~~~~~~~~~~
 
456
 
 
457
Defines the behaviour of signing revisions on commits.  By default bzr will not
 
458
sign new commits.
247
459
 
248
460
always
249
 
    Sign every new revision that is committed.
 
461
    Sign every new revision that is committed.  If the signing fails then the
 
462
    commit will not be made.
250
463
 
251
464
when-required
252
 
    (default) Sign newly committed revisions only when the branch requires
253
 
    signed revisions.
 
465
    Reserved for future use.
254
466
 
255
467
never
256
 
    Refuse to sign newly committed revisions, even if the branch
257
 
    requires signatures.
 
468
    Reserved for future use.
 
469
 
 
470
In future it is planned that ``when-required`` will sign newly
 
471
committed revisions only when the branch requires them.  ``never`` will refuse
 
472
to sign newly committed revisions, even if the branch requires signatures.
 
473
 
 
474
dirstate.fdatasync
 
475
~~~~~~~~~~~~~~~~~~
 
476
 
 
477
If true (default), working tree metadata changes are flushed through the
 
478
OS buffers to physical disk.  This is somewhat slower, but means data
 
479
should not be lost if the machine crashes.  See also repository.fdatasync.
 
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``.
258
487
 
259
488
recurse
260
 
-------
 
489
~~~~~~~
 
490
 
261
491
Only useful in ``locations.conf``. Defines whether or not the
262
492
configuration for this section applies to subdirectories:
263
493
 
269
499
    branches below it.
270
500
 
271
501
gpg_signing_command
272
 
-------------------
 
502
~~~~~~~~~~~~~~~~~~~
 
503
 
273
504
(Default: "gpg"). Which program should be used to sign and check revisions.
274
505
For example::
275
506
 
276
507
    gpg_signing_command = /usr/bin/gnpg
277
508
 
 
509
The specified command must accept the options "--clearsign" and "-u <email>".
 
510
 
278
511
bzr_remote_path
279
 
---------------
 
512
~~~~~~~~~~~~~~~
 
513
 
280
514
(Default: "bzr").  The path to the command that should be used to run the smart
281
515
server for bzr.  This value may only be specified in locations.conf, because:
282
516
 
287
521
It is overridden by the BZR_REMOTE_PATH environment variable.
288
522
 
289
523
smtp_server
290
 
-----------
 
524
~~~~~~~~~~~
 
525
 
291
526
(Default: "localhost"). SMTP server to use when Bazaar needs to send
292
527
email, eg. with ``merge-directive --mail-to``, or the bzr-email plugin.
293
528
 
294
529
smtp_username, smtp_password
295
 
----------------------------
 
530
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
531
 
296
532
User and password to authenticate to the SMTP server. If smtp_username
297
533
is set, and smtp_password is not, Bazaar will prompt for a password.
298
534
These settings are only needed if the SMTP server requires authentication
299
535
to send mail.
300
536
 
 
537
locks.steal_dead
 
538
~~~~~~~~~~~~~~~~
 
539
 
 
540
If set to true, bzr will automatically break locks held by processes from
 
541
the same machine and user that are no longer alive.  Otherwise, it will
 
542
print a message and you can break the lock manually, if you are satisfied
 
543
the object is no longer in use.
 
544
 
301
545
mail_client
302
 
-----------
 
546
~~~~~~~~~~~
 
547
 
303
548
A mail client to use for sending merge requests.
304
549
By default, bzr will try to use ``mapi`` on Windows.  On other platforms, it
305
550
will try ``xdg-email``. If either of these fails, it will fall back to
307
552
 
308
553
Supported values for specific clients:
309
554
 
 
555
:claws: Use Claws.  This skips a dialog for attaching files.
310
556
:evolution: Use Evolution.
311
557
:kmail: Use KMail.
312
558
:mutt: Use Mutt.
322
568
:mapi: Use your preferred e-mail client on Windows.
323
569
:xdg-email: Use xdg-email to run your preferred mail program
324
570
 
 
571
repository.fdatasync
 
572
~~~~~~~~~~~~~~~~~~~~
 
573
 
 
574
If true (default), repository changes are flushed through the OS buffers
 
575
to physical disk.  This is somewhat slower, but means data should not be
 
576
lost if the machine crashes.  See also dirstate.fdatasync.
 
577
 
325
578
submit_branch
326
 
-------------
 
579
~~~~~~~~~~~~~
 
580
 
327
581
The branch you intend to submit your current work to.  This is automatically
328
582
set by ``bzr send``, and is also used by the ``submit:`` revision spec.  This
329
583
should usually be set on a per-branch or per-location basis.
330
584
 
331
585
public_branch
332
 
-------------
 
586
~~~~~~~~~~~~~
 
587
 
333
588
A publically-accessible version of this branch (implying that this version is
334
589
not publically-accessible).  Used (and set) by ``bzr send``.
335
590
 
336
 
 
337
 
Branch 6 Options
338
 
================
339
 
 
340
 
These options apply only to branches that use the "dirstate-tags" format.  They
 
591
suppress_warnings
 
592
~~~~~~~~~~~~~~~~~
 
593
 
 
594
A list of strings, each string represent a warning that can be emitted by
 
595
bzr. Mentioning a warning in this list tells bzr to not emit it.
 
596
 
 
597
Valid values:
 
598
 
 
599
* ``format_deprecation``:
 
600
    whether the format deprecation warning is shown on repositories that are
 
601
    using deprecated formats.
 
602
 
 
603
default_format
 
604
~~~~~~~~~~~~~~
 
605
 
 
606
A format name for the default format used when creating branches.  See ``bzr
 
607
help formats`` for possible values.
 
608
 
 
609
 
 
610
Unicode options
 
611
---------------
 
612
 
 
613
output_encoding
 
614
~~~~~~~~~~~~~~~
 
615
 
 
616
A Python unicode encoding name for text output from bzr, such as log
 
617
information.  Values include: utf8, cp850, ascii, iso-8859-1.  The default
 
618
is the terminal encoding prefered by the operating system.
 
619
 
 
620
 
 
621
Branch type specific options
 
622
----------------------------
 
623
 
 
624
These options apply only to branches that use the ``dirstate-tags`` or
 
625
later format.  They
341
626
are usually set in ``.bzr/branch/branch.conf`` automatically, but may be
342
627
manually set in ``locations.conf`` or ``bazaar.conf``.
343
628
 
344
629
append_revisions_only
345
 
---------------------
 
630
~~~~~~~~~~~~~~~~~~~~~
 
631
 
346
632
If set to "True" then revisions can only be appended to the log, not
347
 
removed.  A branch with this setting enabled can only pull from
348
 
another branch if the other branch's log is a longer version of its
349
 
own.  This is normally set by ``bzr init --append-revisions-only``.
 
633
removed.  A branch with this setting enabled can only pull from another
 
634
branch if the other branch's log is a longer version of its own.  This is
 
635
normally set by ``bzr init --append-revisions-only``. If you set it
 
636
manually, use either 'True' or 'False' (case-sensitive) to maintain
 
637
compatibility with previous bzr versions (older than 2.2).
350
638
 
351
639
parent_location
352
 
---------------
353
 
If present, the location of the default branch for pull or merge.
354
 
This option is normally set by ``pull --remember`` or ``merge
 
640
~~~~~~~~~~~~~~~
 
641
 
 
642
If present, the location of the default branch for pull or merge.  This option
 
643
is normally set when creating a branch, the first ``pull`` or by ``pull
355
644
--remember``.
356
645
 
357
646
push_location
358
 
-------------
 
647
~~~~~~~~~~~~~
 
648
 
359
649
If present, the location of the default branch for push.  This option
360
 
is normally set by ``push --remember``.
 
650
is normally set by the first ``push`` or ``push --remember``.
 
651
 
 
652
push_strict
 
653
~~~~~~~~~~~
 
654
 
 
655
If present, defines the ``--strict`` option default value for checking
 
656
uncommitted changes before pushing.
 
657
 
 
658
dpush_strict
 
659
~~~~~~~~~~~~
 
660
 
 
661
If present, defines the ``--strict`` option default value for checking
 
662
uncommitted changes before pushing into a different VCS without any
 
663
custom bzr metadata.
361
664
 
362
665
bound_location
363
 
--------------
 
666
~~~~~~~~~~~~~~
 
667
 
364
668
The location that commits should go to when acting as a checkout.
365
669
This option is normally set by ``bind``.
366
670
 
367
671
bound
368
 
-----
 
672
~~~~~
 
673
 
369
674
If set to "True", the branch should act as a checkout, and push each commit to
370
675
the bound_location.  This option is normally set by ``bind``/``unbind``.
371
676
 
 
677
send_strict
 
678
~~~~~~~~~~~
 
679
 
 
680
If present, defines the ``--strict`` option default value for checking
 
681
uncommitted changes before sending a merge directive.
 
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.
 
691
 
 
692
External Merge Tools
 
693
--------------------
 
694
 
 
695
bzr.mergetool.<name>
 
696
~~~~~~~~~~~~~~~~~~~~
 
697
 
 
698
Defines an external merge tool called <name> with the given command-line.
 
699
Arguments containing spaces should be quoted using single or double quotes. The
 
700
executable may omit its path if it can be found on the PATH.
 
701
 
 
702
The following markers can be used in the command-line to substitute filenames
 
703
involved in the merge conflict::
 
704
 
 
705
  {base}      file.BASE
 
706
  {this}      file.THIS
 
707
  {other}     file.OTHER
 
708
  {result}    output file
 
709
  {this_temp} temp copy of file.THIS, used to overwrite output file if merge
 
710
              succeeds.
 
711
 
 
712
For example::
 
713
 
 
714
  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
 
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
 
 
732
bzr.default_mergetool
 
733
~~~~~~~~~~~~~~~~~~~~~
 
734
 
 
735
Specifies which external merge tool (as defined above) should be selected by
 
736
default in tools such as ``bzr qconflicts``.
 
737
 
 
738
For example::
 
739
 
 
740
  bzr.default_mergetool = kdiff3