/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 bzrlib/help_topics/en/configuration.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-02-11 04:02:41 UTC
  • mfrom: (5017.2.2 tariff)
  • Revision ID: pqm@pqm.ubuntu.com-20100211040241-w6n021dz0uus341n
(mbp) add import-tariff tests

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/help_topics/en/configuration.txt
7
7
While most configuration is handled by configuration files, some options
8
8
which may be semi-permanent can also be controlled through the environment.
9
9
 
10
 
BRZ_EMAIL
 
10
BZR_EMAIL
11
11
~~~~~~~~~
12
12
 
13
 
Override the email id used by Breezy.  Typical format::
 
13
Override the email id used by Bazaar.  Typical format::
14
14
 
15
15
  "John Doe <jdoe@example.com>"
16
16
 
17
 
See also the ``email`` configuration option.
 
17
See also the ``email`` configuration value.
18
18
 
19
 
BRZ_PROGRESS_BAR
 
19
BZR_PROGRESS_BAR
20
20
~~~~~~~~~~~~~~~~
21
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.
 
22
Override the progress display.  Possible values are "none", "dots", "tty"
25
23
 
26
 
BRZ_SIGQUIT_PDB
 
24
BZR_SIGQUIT_PDB
27
25
~~~~~~~~~~~~~~~
28
26
 
29
27
Control whether SIGQUIT behaves normally or invokes a breakin debugger.
31
29
* 0 = Standard SIGQUIT behavior (normally, exit with a core dump)
32
30
* 1 = Invoke breakin debugger (default)
33
31
 
34
 
BRZ_HOME
 
32
BZR_HOME
35
33
~~~~~~~~
36
34
 
37
 
Override the home directory used by Breezy.
 
35
Override the home directory used by Bazaar.
38
36
 
39
 
BRZ_SSH
 
37
BZR_SSH
40
38
~~~~~~~
41
39
 
42
40
Select a different SSH implementation.
43
41
 
44
 
BRZ_PDB
 
42
BZR_PDB
45
43
~~~~~~~
46
44
 
47
45
Control whether to launch a debugger on error.
52
50
BZR_REMOTE_PATH
53
51
~~~~~~~~~~~~~~~
54
52
 
55
 
Path to the Bazaar or Breezy executable to use when using the bzr+ssh protocol.
56
 
 
57
 
See also the ``bzr_remote_path`` configuration option.
58
 
 
59
 
BRZ_EDITOR
 
53
Path to the Bazaar executable to use when using the bzr+ssh protocol.
 
54
 
 
55
See also the ``bzr_remote_path`` configuration value.
 
56
 
 
57
BZR_EDITOR
60
58
~~~~~~~~~~
61
59
 
62
 
Path to the editor Breezy should use for commit messages, etc.
63
 
 
64
 
BRZ_LOG
65
 
~~~~~~~
66
 
 
67
 
Location of the Breezy 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 Breezy.
72
 
 
73
 
Setting this to ``NUL`` on Windows or ``/dev/null`` on other platforms
74
 
will disable logging.
75
 
 
76
 
 
77
 
BRZ_PLUGIN_PATH
 
60
Path to the editor Bazaar should use for commit messages, etc.
 
61
 
 
62
BZR_PLUGIN_PATH
78
63
~~~~~~~~~~~~~~~
79
64
 
80
 
The path to the plugins directory that Breezy should use.
81
 
If not set, Breezy will search for plugins in:
 
65
The path to the plugins directory that Bazaar should use.
 
66
If not set, Bazaar will search for plugins in:
82
67
 
83
68
* the user specific plugin directory (containing the ``user`` plugins),
84
69
 
85
 
* the breezy directory (containing the ``core`` plugins),
 
70
* the bzrlib directory (containing the ``core`` plugins),
86
71
 
87
72
* the site specific plugin directory if applicable (containing
88
73
  the ``site`` plugins).
92
77
 
93
78
As for the ``PATH`` variables, if multiple directories are
94
79
specified in ``BZR_PLUGIN_PATH`` they should be separated by the
95
 
platform specific appropriate character (':' on Unix,
 
80
platform specific appropriate character (':' on Unix/Linux/etc,
96
81
';' on windows)
97
82
 
98
83
By default if ``BZR_PLUGIN_PATH`` is set, it replaces searching
113
98
used literally, they will be substituted by the corresponding,
114
99
platform specific, values.
115
100
 
116
 
The examples below use ':' as the separator, windows users
 
101
Examples:
 
102
^^^^^^^^^
 
103
 
 
104
The examples below uses ':' as the separator, windows users
117
105
should use ';'.
118
106
 
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
 
BRZ_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
 
BRZ_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``
177
 
 
178
 
BRZPATH
 
107
Overriding the default user plugin directory:
 
108
``BZR_PLUGIN_PATH='/path/to/my/other/plugins'``
 
109
 
 
110
Disabling the site directory while retaining the user directory:
 
111
``BZR_PLUGIN_PATH='-site:+user'``
 
112
 
 
113
Disabling all plugins (better achieved with --no-plugins):
 
114
``BZR_PLUGIN_PATH='-user:-core:-site'``
 
115
 
 
116
Overriding the default site plugin directory:
 
117
``BZR_PLUGIN_PATH='/path/to/my/site/plugins:-site':+user``
 
118
 
 
119
 
 
120
 
 
121
BZRPATH
179
122
~~~~~~~
180
123
 
181
 
The path where Breezy should look for shell plugin external commands.
182
 
 
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/
 
124
The path where Bazaar should look for shell plugin external commands.
191
125
 
192
126
 
193
127
Configuration files
196
130
Location
197
131
~~~~~~~~
198
132
 
199
 
Configuration files are located in ``$HOME/.bazaar`` on Unix and
200
 
``C:\Documents and Settings\<username>\Application Data\Breezy\2.0`` on
 
133
Configuration files are located in ``$HOME/.bazaar`` on Linux/Unix and
 
134
``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
201
135
Windows. (You can check the location for your system by using
202
136
``bzr version``.)
203
137
 
204
138
There are three primary configuration files in this location:
205
139
 
206
 
* ``breezy.conf`` describes default configuration options,
 
140
* ``bazaar.conf`` describes default configuration options,
207
141
 
208
142
* ``locations.conf`` describes configuration information for
209
143
  specific branch locations,
221
155
~~~~~~~~~~~~~~
222
156
 
223
157
An ini file has three types of contructs: section headers, section
224
 
options and comments.
 
158
variables and comments.
225
159
 
226
160
Comments
227
161
^^^^^^^^
228
162
 
229
163
A comment is any line that starts with a "#" (sometimes called a "hash
230
164
mark", "pound sign" or "number sign"). Comment lines are ignored by
231
 
Breezy when parsing ini files.
 
165
Bazaar when parsing ini files.
232
166
 
233
167
Section headers
234
168
^^^^^^^^^^^^^^^
238
172
 
239
173
    [DEFAULT]
240
174
 
241
 
The only valid section headers for breezy.conf currently are [DEFAULT] and
 
175
The only valid section headers for bazaar.conf currently are [DEFAULT] and
242
176
[ALIASES].  Section headers are case sensitive. The default section provides for
243
 
setting options which can be overridden with the branch config file.
 
177
setting variables which can be overridden with the branch config file.
244
178
 
245
 
For ``locations.conf``, the options from the section with the
 
179
For ``locations.conf``, the variables from the section with the
246
180
longest matching section header are used to the exclusion of other
247
181
potentially valid section headers. A section header uses the path for
248
182
the branch as the section header. Some examples include::
251
185
    [/home/jdoe/branches/]
252
186
 
253
187
 
254
 
Section options
255
 
^^^^^^^^^^^^^^^
 
188
Section variables
 
189
^^^^^^^^^^^^^^^^^
256
190
 
257
 
A section option resides within a section. A section option contains an
258
 
option name, an equals sign and a value.  For example::
 
191
A section variable resides within a section. A section variable contains a
 
192
variable name, an equals sign and a value.  For example::
259
193
 
260
194
    email            = John Doe <jdoe@isp.com>
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
 
195
    check_signatures = require
 
196
 
 
197
 
 
198
Variable policies
 
199
^^^^^^^^^^^^^^^^^
 
200
 
 
201
Variables defined in a section affect the named directory or URL plus
 
202
any locations they contain.  Policies can be used to change how a
 
203
variable value is interpreted for contained locations.  Currently
275
204
there are three policies available:
276
205
 
277
206
 none:
284
213
   for contained locations, any additional path components are
285
214
   appended to the value.
286
215
 
287
 
Policies are specified by keys with names of the form "<option_name>:policy".
 
216
Policies are specified by keys with names of the form "$var:policy".
288
217
For example, to define the push location for a tree of branches, the
289
218
following could be used::
290
219
 
295
224
With this configuration, the push location for ``/top/location/branch1``
296
225
would be ``sftp://example.com/location/branch1``.
297
226
 
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
 
 
352
 
 
353
 
The main configuration file, breezy.conf
 
227
 
 
228
The main configuration file, bazaar.conf
354
229
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
355
230
 
356
 
``breezy.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
 
231
``bazaar.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
357
232
The default section contains the default
358
233
configuration options for all branches. The default section can be
359
234
overriden by providing a branch-specific section in ``locations.conf``.
360
235
 
361
 
A typical ``breezy.conf`` section often looks like the following::
 
236
A typical ``bazaar.conf`` section often looks like the following::
362
237
 
363
238
    [DEFAULT]
364
239
    email             = John Doe <jdoe@isp.com>
365
240
    editor            = /usr/bin/vim
 
241
    check_signatures  = check-available
366
242
    create_signatures = when-required
367
243
 
368
244
 
371
247
 
372
248
``locations.conf`` allows one to specify overriding settings for
373
249
a specific branch. The format is almost identical to the default section in
374
 
breezy.conf with one significant change: The section header, instead of saying
 
250
bazaar.conf with one significant change: The section header, instead of saying
375
251
default, will be the path to a branch that you wish to override a value
376
252
for. The '?' and '*' wildcards are supported::
377
253
 
380
256
 
381
257
    [http://hypothetical.site.com/branches/devel-branch]
382
258
    create_signatures = always
 
259
    check_signatures  = always
 
260
 
 
261
    [http://bazaar-vcs.org/bzr/*]
 
262
    check_signatures  = require
383
263
 
384
264
The authentication configuration file, authentication.conf
385
265
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
389
269
of bzr that requires authentication (smtp for example).
390
270
 
391
271
The syntax of the file obeys the same rules as the others except for the
392
 
option policies which don't apply.
 
272
variable policies which don't apply.
393
273
 
394
274
For more information on the possible uses of the authentication configuration
395
275
file see :doc:`authentication-help`.
396
276
 
397
277
 
398
 
Common options
399
 
--------------
 
278
Common variable options
 
279
-----------------------
400
280
 
401
281
debug_flags
402
282
~~~~~~~~~~~
407
287
 
408
288
    debug_flags = hpss
409
289
 
410
 
or::
411
 
 
412
 
    debug_flags = hpss,evil
413
 
 
414
290
email
415
291
~~~~~
416
292
 
437
313
check_signatures
438
314
~~~~~~~~~~~~~~~~
439
315
 
440
 
Reserved for future use.  These options will allow a policy for branches to
441
 
require signatures.
 
316
Defines the behavior for signatures.
442
317
 
443
318
require
444
319
    The gnupg signature for revisions must be present and must be valid.
448
323
 
449
324
check-available
450
325
    (default) If gnupg signatures for revisions are present, check them.
451
 
    Breezy will fail if it finds a bad signature, but will not fail if
 
326
    Bazaar will fail if it finds a bad signature, but will not fail if
452
327
    no signature is present.
453
328
 
454
329
create_signatures
455
330
~~~~~~~~~~~~~~~~~
456
331
 
457
 
Defines the behaviour of signing revisions on commits.  By default bzr will not
458
 
sign new commits.
 
332
Defines the behaviour of signing revisions.
459
333
 
460
334
always
461
 
    Sign every new revision that is committed.  If the signing fails then the
462
 
    commit will not be made.
 
335
    Sign every new revision that is committed.
463
336
 
464
337
when-required
465
 
    Reserved for future use.
 
338
    (default) Sign newly committed revisions only when the branch requires
 
339
    signed revisions.
466
340
 
467
341
never
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" Breezy will use the user e-mail set with ``whoami``.
 
342
    Refuse to sign newly committed revisions, even if the branch
 
343
    requires signatures.
487
344
 
488
345
recurse
489
346
~~~~~~~
498
355
    This section only applies to the branch at this directory and not
499
356
    branches below it.
500
357
 
 
358
gpg_signing_command
 
359
~~~~~~~~~~~~~~~~~~~
 
360
 
 
361
(Default: "gpg"). Which program should be used to sign and check revisions.
 
362
For example::
 
363
 
 
364
    gpg_signing_command = /usr/bin/gnpg
 
365
 
501
366
bzr_remote_path
502
367
~~~~~~~~~~~~~~~
503
368
 
513
378
smtp_server
514
379
~~~~~~~~~~~
515
380
 
516
 
(Default: "localhost"). SMTP server to use when Breezy needs to send
 
381
(Default: "localhost"). SMTP server to use when Bazaar needs to send
517
382
email, eg. with ``merge-directive --mail-to``, or the bzr-email plugin.
518
383
 
519
384
smtp_username, smtp_password
520
385
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
521
386
 
522
387
User and password to authenticate to the SMTP server. If smtp_username
523
 
is set, and smtp_password is not, Breezy will prompt for a password.
 
388
is set, and smtp_password is not, Bazaar will prompt for a password.
524
389
These settings are only needed if the SMTP server requires authentication
525
390
to send mail.
526
391
 
527
 
locks.steal_dead
528
 
~~~~~~~~~~~~~~~~
529
 
 
530
 
By default, bzr will automatically break locks held by processes from
531
 
the same machine and user that are no longer alive.  If disabled, it will
532
 
print a message and you can break the lock manually, if you are satisfied
533
 
the object is no longer in use.
534
 
 
535
392
mail_client
536
393
~~~~~~~~~~~
537
394
 
558
415
:mapi: Use your preferred e-mail client on Windows.
559
416
:xdg-email: Use xdg-email to run your preferred mail program
560
417
 
561
 
repository.fdatasync
562
 
~~~~~~~~~~~~~~~~~~~~
563
 
 
564
 
If true (default), repository changes are flushed through the OS buffers
565
 
to physical disk.  This is somewhat slower, but means data should not be
566
 
lost if the machine crashes.  See also dirstate.fdatasync.
567
 
 
568
418
submit_branch
569
419
~~~~~~~~~~~~~
570
420
 
590
440
    whether the format deprecation warning is shown on repositories that are
591
441
    using deprecated formats.
592
442
 
593
 
* ``insecure_permissions``:
594
 
    whether a warning is shown if ``authentication.conf`` can be read
595
 
    by other users.
596
 
 
597
 
default_format
598
 
~~~~~~~~~~~~~~
599
 
 
600
 
A format name for the default format used when creating branches.  See ``bzr
601
 
help formats`` for possible values.
602
 
 
603
 
 
604
 
Unicode options
605
 
---------------
606
 
 
607
 
output_encoding
608
 
~~~~~~~~~~~~~~~
609
 
 
610
 
A Python unicode encoding name for text output from bzr, such as log
611
 
information.  Values include: utf8, cp850, ascii, iso-8859-1.  The default
612
 
is the terminal encoding prefered by the operating system.
613
 
 
614
443
 
615
444
Branch type specific options
616
445
----------------------------
618
447
These options apply only to branches that use the ``dirstate-tags`` or
619
448
later format.  They
620
449
are usually set in ``.bzr/branch/branch.conf`` automatically, but may be
621
 
manually set in ``locations.conf`` or ``breezy.conf``.
 
450
manually set in ``locations.conf`` or ``bazaar.conf``.
622
451
 
623
452
append_revisions_only
624
453
~~~~~~~~~~~~~~~~~~~~~
625
454
 
626
455
If set to "True" then revisions can only be appended to the log, not
627
 
removed.  A branch with this setting enabled can only pull from another
628
 
branch if the other branch's log is a longer version of its own.  This is
629
 
normally set by ``bzr init --append-revisions-only``. If you set it
630
 
manually, use either 'True' or 'False' (case-sensitive) to maintain
631
 
compatibility with previous bzr versions (older than 2.2).
 
456
removed.  A branch with this setting enabled can only pull from
 
457
another branch if the other branch's log is a longer version of its
 
458
own.  This is normally set by ``bzr init --append-revisions-only``.
632
459
 
633
460
parent_location
634
461
~~~~~~~~~~~~~~~
635
462
 
636
 
If present, the location of the default branch for pull or merge.  This option
637
 
is normally set when creating a branch, the first ``pull`` or by ``pull
 
463
If present, the location of the default branch for pull or merge.
 
464
This option is normally set by ``pull --remember`` or ``merge
638
465
--remember``.
639
466
 
640
467
push_location
641
468
~~~~~~~~~~~~~
642
469
 
643
470
If present, the location of the default branch for push.  This option
644
 
is normally set by the first ``push`` or ``push --remember``.
 
471
is normally set by ``push --remember``.
645
472
 
646
473
push_strict
647
474
~~~~~~~~~~~
649
476
If present, defines the ``--strict`` option default value for checking
650
477
uncommitted changes before pushing.
651
478
 
 
479
dpush_strict
 
480
~~~~~~~~~~~~
 
481
 
 
482
If present, defines the ``--strict`` option default value for checking
 
483
uncommitted changes before pushing into a different VCS without any
 
484
custom bzr metadata.
 
485
 
652
486
bound_location
653
487
~~~~~~~~~~~~~~
654
488
 
667
501
If present, defines the ``--strict`` option default value for checking
668
502
uncommitted changes before sending a merge directive.
669
503
 
670
 
add.maximum_file_size
671
 
~~~~~~~~~~~~~~~~~~~~~
672
 
 
673
 
Defines the maximum file size the command line "add" operation will allow
674
 
in recursive mode, with files larger than this value being skipped. You may 
675
 
specify this value as an integer (in which case it is interpreted as bytes), 
676
 
or you may specify the value using SI units, i.e. 10KB, 20MB, 1G. A value of 0 
677
 
will disable skipping.
678
 
 
679
 
External Merge Tools
680
 
--------------------
681
 
 
682
 
bzr.mergetool.<name>
683
 
~~~~~~~~~~~~~~~~~~~~
684
 
 
685
 
Defines an external merge tool called <name> with the given command-line.
686
 
Arguments containing spaces should be quoted using single or double quotes. The
687
 
executable may omit its path if it can be found on the PATH.
688
 
 
689
 
The following markers can be used in the command-line to substitute filenames
690
 
involved in the merge conflict::
691
 
 
692
 
  {base}      file.BASE
693
 
  {this}      file.THIS
694
 
  {other}     file.OTHER
695
 
  {result}    output file
696
 
  {this_temp} temp copy of file.THIS, used to overwrite output file if merge
697
 
              succeeds.
698
 
 
699
 
For example::
700
 
 
701
 
  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
702
 
 
703
 
Because ``mergetool`` and ``config`` itself both use curly braces as
704
 
interpolation markers, trying to display the mergetool line results in the
705
 
following problem::
706
 
 
707
 
 
708
 
  $ bzr config bzr.mergetool.kdiff3='kdiff3 {base} {this} {other} -o {result}'
709
 
  $ bzr config bzr.mergetool.kdiff3
710
 
  bzr: ERROR: Option base is not defined while expanding "kdiff3 {base} {this} {other} -o {result}".
711
 
 
712
 
To avoid this, ``config`` can be instructed not to try expanding variables::
713
 
 
714
 
  $ bzr config --all bzr.mergetool.kdiff3
715
 
  branch:
716
 
    bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
717
 
 
718
 
 
719
 
bzr.default_mergetool
720
 
~~~~~~~~~~~~~~~~~~~~~
721
 
 
722
 
Specifies which external merge tool (as defined above) should be selected by
723
 
default in tools such as ``bzr qconflicts``.
724
 
 
725
 
For example::
726
 
 
727
 
  bzr.default_mergetool = kdiff3