~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2011-08-17 18:13:57 UTC
  • mfrom: (5268.7.29 transport-segments)
  • Revision ID: pqm@pqm.ubuntu.com-20110817181357-y5q5eth1hk8bl3om
(jelmer) Allow specifying the colocated branch to use in the branch URL,
 and retrieving the branch name using ControlDir._get_selected_branch.
 (Jelmer Vernooij)

Show diffs side-by-side

added added

removed removed

Lines of Context:
221
221
~~~~~~~~~~~~~~
222
222
 
223
223
An ini file has three types of contructs: section headers, section
224
 
options and comments.
 
224
variables 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 options which can be overridden with the branch config file.
 
243
setting variables which can be overridden with the branch config file.
244
244
 
245
 
For ``locations.conf``, the options from the section with the
 
245
For ``locations.conf``, the variables 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 options
255
 
^^^^^^^^^^^^^^^
 
254
Section variables
 
255
^^^^^^^^^^^^^^^^^
256
256
 
257
 
A section option resides within a section. A section option contains an
258
 
option name, an equals sign and a value.  For example::
 
257
A section variable resides within a section. A section variable contains a
 
258
variable 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 option can reference other options by enclosing them in curly brackets::
 
263
A variable can reference other variables **in the same configuration file** by
 
264
enclosing them in curly brackets::
264
265
 
265
266
    my_branch_name = feature_x
266
267
    my_server      = bzr+ssh://example.com
267
268
    push_location   = {my_server}/project/{my_branch_name}
268
269
 
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
 
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
275
277
there are three policies available:
276
278
 
277
279
 none:
284
286
   for contained locations, any additional path components are
285
287
   appended to the value.
286
288
 
287
 
Policies are specified by keys with names of the form "<option_name>:policy".
 
289
Policies are specified by keys with names of the form "$var:policy".
288
290
For example, to define the push location for a tree of branches, the
289
291
following could be used::
290
292
 
295
297
With this configuration, the push location for ``/top/location/branch1``
296
298
would be ``sftp://example.com/location/branch1``.
297
299
 
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
300
 
353
301
The main configuration file, bazaar.conf
354
302
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
389
337
of bzr that requires authentication (smtp for example).
390
338
 
391
339
The syntax of the file obeys the same rules as the others except for the
392
 
option policies which don't apply.
 
340
variable policies which don't apply.
393
341
 
394
342
For more information on the possible uses of the authentication configuration
395
343
file see :doc:`authentication-help`.
396
344
 
397
345
 
398
 
Common options
399
 
--------------
 
346
Common variable options
 
347
-----------------------
400
348
 
401
349
debug_flags
402
350
~~~~~~~~~~~
680
628
If present, defines the ``--strict`` option default value for checking
681
629
uncommitted changes before sending a merge directive.
682
630
 
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
631
 
692
632
External Merge Tools
693
633
--------------------
713
653
 
714
654
  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
715
655
 
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
656
bzr.default_mergetool
733
657
~~~~~~~~~~~~~~~~~~~~~
734
658