~bzr-pqm/bzr/bzr.dev

.. This file is autogenerated from the output of

..     bzr help topics

..     bzr help commands

..     bzr help <cmd>

..

.. Generation time: 2009-01-09 07:03:09 +0000

##########################

Bazaarユーザーリファレンス

##########################

:Version:   1.11

:Generated: 2009-01-09

.. contents:: :depth: 2

-----

このチュートリアルについて

##########################

このマニュアルはBazaarのオンラインヘルプから生成されました。オンラインヘルプのシステムを

利用するためには次のコマンドを試してください。

    よく使われるコマンドの一覧を含めて紹介します::

        bzr help

    トピックの一覧とそれぞれの要約::

        bzr help topics

    コマンドの一覧とそれぞれの要約::

        bzr help commands

    特定のトピックもしくはコマンドに関する詳細な情報::

        bzr help topic-or-command-name

次のウェブサイトはBazaarに関する詳細な情報を提供します:

:ホームページ:                     http://www.bazaar-vcs.org/

:公式ドキュメント:                 http://doc.bazaar-vcs.org/

:Launchpad:                     https://launchpad.net/bzr/

概念

####

ブランチ

=========

ブランチは、すべての履歴を含む、プロジェクトの状態で構成されます。 

すべてのブランチは関連づけされたリポジトリ(ブランチの履歴が保存される場所)を持ちますが、

複数のブランチは同じリポジトリを共有することもあります(共用リポジトリ)。

ブランチはコピーしたりマージしたりできます。

関連コマンド::

  init    ディレクトリをバージョン管理されたブランチに変更する。

  branch  ブランチの新しいコピーを作成する。

  merge   3方向マージ (3-way merge) を実行する。

チェックアウト

==============

チェックアウトはブランチに結びつけられたソースツリーなので、

ソースツリーにコミットするときに、コミットの内容はブランチに格納されます。

必要になるまでBazaarの分散型機能の一部を無視して、よりシンプルに、集中型のワークフローを利用できます。

共用リポジトリでチェックアウトを利用することはSVNもしくはCVSでの作業とよく似ていますが、同じ制限を持ちません。

そしてチェックアウトを利用することで望むワークフローがなんであれ他の人もプロジェクトに取り組むことができます。

チェックアウトはbzr checkoutコマンド("help checkout"を参照)によって作成されます。

これに別のブランチへのリファレンスを渡し、マスターブランチからのチェックアウトを作成したブランチへのリファレンスを

まだ含むローカルコピーを作成します。

何かコミットをすればこれらは他のブランチで最初に作成されます。

これによって作業内容のインスタントミラーが作成されるもしくは

それぞれの開発者が共同で作業して他の人の変更を継続的に統合するロックステップ開発を円滑にします。

しかしながらチェックアウトはまだBazaarの第一級のブランチで、すべての履歴をローカルで保存できます。

第一級のブランチがあるので、ローカルにコミットすることもできます。

たとえば、ネットワーク接続による一時的な遅延を回避したいのであれば、ローカルでもコミットできます。

これを行うには --local オプションを使います。

次にローカルではないコミットを行うときにすべてのローカルコミットはマスターブランチに行われます。

共用ブランチからのチェックアウトを使用しているとき、周期的に他の人による変更をすべてpullしたくなります。

これは"update"コマンドによってできます。

ローカルではないコミットの前に変更が適用される必要がありますが、

Bazaarは変更が存在することを伝え必要なときにこのコマンドを使うように提示します。

checkoutコマンドに--lightweightフラグを渡すことで"軽量"チェックアウトを作成することも可能です。

第一級のブランチではなく、主に作業ツリーで構成されるという点で、軽量チェックアウトはSVNのチェックアウトにより近いです。

履歴のオペレーションはマスターブランチに問い合わせをしなければならないので、

ネットワーク接続が関わる場合遅くなる可能性があることを意味します。

また、ローカルブランチを持たないので、ローカルでコミットできません。

マスターブランチに高速で信頼性のあるアクセス権限があるときに軽量チェックアウトは最も良く動作します。

マスターブランチが同じディスクもしくはLAN上にあれば、(ブランチのコピーの更新だけが必要なので)

リビジョンを変更するどのコマンドでも軽量ブランチは重量ブランチよりも速くなることを意味します。

一般的に重量チェックアウトは速いですが、マスターブランチが同じディスク上のあるときは、顕著な違いはありません。

チェックアウトの別の使い方はブランチを格納するツリーなしのリポジトリで使うことです。

ここでは異なるブランチに取り組むときチェックアウトが指定するマスターブランチを切り替えることで

1つの作業ツリーだけを維持します。

明確にチェックアウトにコミットするにはマスターブランチへの書き込み権限が必要です。

マスターブランチはsftp://といった書き込み可能なプロトコルでアクセスしなければならないので、

相手方で書き込み権限をもたなければならないことを意味します。

チェックアウトはローカルファイルシステムでも機能するので、すべての問題はファイルのパーミッションです。

"bind"コマンド("help bind"を参照)を使用することでチェックアウトのマスターを変更できます。

これによってコミットが送信される位置が変更されます。

bindコマンドはブランチをheavyチェックアウトに変換するためにも使用できます。

すべてのコミットがローカルで行われるようにheavyチェックアウトを通常のブランチに変換したい場合、

"unbind" コマンドを使用できます。

関連コマンド::

  checkout    チェックアウトを作成する。軽量チェックアウトを得るには --lightweight を渡す

  update      マスターブランチの変更をあなたのチェックアウトにpullする

  commit      マスターブランチに送信されるコミットを行う。

              重量チェックアウトであれば --localオプションによって

              マスターにコミットを送信せずにチェックアウトにコミットされます

  bind        送信されるチェックアウトにコミットされるマスターブランチを変更する

  unbind      コミットがローカルだけで行われるように重量チェックアウトをスタンドアロンのブランチに変換する

クリスクロス

============

ブランチの履歴のクリスクロス(Criss-cross)は通常期待されるよりも多くのコンフリクトを出すデフォルトのマージテクニックを必要とします。

複雑なマージの場合、 ``bzr merge --lca`` もしくは ``bzr merge --weave`` ではよりよい結果になるかもしれません。

作業ツリーを ``bzr revert`` して再度マージしたいと願うかもしれません。

代わりに、特定の衝突しているファイル上で ``bzr remerge`` を使います。

2つのブランチが同じものをマージしてお互いにマージし合う場合、

もしくは2つのブランチが同時にお互いをマージする場合、クリスクロスはブランチの中で発生します。

それぞれのブランチが目的の集中型ブランチからもしくはそのブランチからのみマージすることでこれらを回避できます("star topology")。

マージが動作する方法のためクリスクロスは問題を引き起こします。

Bazaarのデフォルトマージは三方向マージです; OTHERをTHISにマージするには比較、BASE用の基本を見つけなければなりません。

BASEを利用することで、THISとOTHERの違いが行を追加するワンサイドか、行を削除する別のサイドによるのかを決定できます。

クリスクロスはベースに関してよい選択肢がないことを意味します。

最近のマージポイントを選択することはワンサイドの変更を少し廃棄してしまう可能性があります。

(Bazaarが行う)古いマージポイントを選択することは余分な衝突が発せられることを意味します。

``weave`` マージタイプはこの問題の影響を受けません。

このタイプは違いの原因を決定するためにベースのリビジョンの代わりに行を起点とする検出方法を利用するからです。

ストレージフォーマット

=======================

古いクライアントが不正にデータにアクセスしないことを保証するために、

Bazaarのポリシーでは新しい機能が新しいメタデータを追加する必要があるときに

新しいフォーマットを導入することにしています。新しいストレージフォーマットは

パフォーマンスとスケーラビリティを改善するために導入することもあります。

フォーマットを選ぶために次のガイドラインを利用します(条件がtrueであると同時に停止):

* 既存のプロジェクトに取り組んでいる場合、プロジェクトが利用しているものを使用します。

  (デフォルトでBazaarはあなたの代わりにこれを行います)。

* Subversionリポジトリと連携するbzr-svnを利用している場合は、

  1.9-rich-rootを使用します。

* 大きなツリー(5000以上のパス)もしくは深い履歴(5000以上のリビジョン)を持つ

  プロジェクトに取り組んでいるのであれば、1.9を使用します。

* さもなければ、デフォルトのフォーマットを使用します。大抵のプロジェクトはこれで十分です。

(ディストロのパッケージを利用しているなどで)最新のBazaarを利用できない開発者がいるのであれば、

それに応じてガイドラインを調整してください。 

たとえば、プロジェクトがBazaar 1.7を標準化している場合、1.9の代わりに1.6を選ぶことが必要です。

注: 現在サポートされるフォーマットの多くは2つのバリアントを持ちます:

plainのものとrich-rootのものです。

後者はツリーのrootに関する追加フィールドを含みます。

rich-rootフォーマットを利用する際にパフォーマンスコストはありませんが

rich-rootフォーマットからの変更をplainフォーマットに簡単にマージできません。

結果として、すべての投稿者がほぼ同時にリポジトリをアップグレードする必要があるので、

プロジェクトをrich-rootフォーマットに移行させるには調整が必要です。

(これまでのところrich-rootフォーマットをデフォルトにすることを遅らせてきた理由です。

将来の適切な時期にこれを行います。)

現在サポートされるフォーマットの完全なリストに関しては ``bzr help current-formats`` を参照してください。

利用可能で実験上もしくは廃止されたフォーマットに関しては ``bzr help other-formats`` を参照してください。

パターン

========

Bazaarはさまざまな時点でマッチするファイルを使用します。

たとえば、 ``add`` コマンドは無視するパターンにマッチするファイルとスキップし

プリファレンスはルールパターンを使用するファイルに関連づけできます。

パターン構文は下記のとおりです。

パターン上のトレーリングスラッシュは無視されます。

パターンがスラッシュを含むもしくは正規表現である場合、ブランチのroot全体から比較されます。

さもなければ、これはパスの最後のコンポーネントのみと比較されます。

rootディレクトリの中のファイルのみにマッチさせるには'./'を用意します。

絶対パスを指定するパターンは許可されていません。

パターンは次のようなglobのワイルドカードを含むことができます::

  ? - '/'以外の単独文字にマッチする

  * - '/'以外の0かそれ以上の文字数にマッチする

  /**/ - パスの中のゼロかそれ以上のディレクトリにマッチする

  [a-z] - 文字のグループの範囲内からの単独の文字にマッチする

パターンはPythonの正規表現にもなります。

正規表現のパターンは 'RE:' の接頭辞で始まる正規表現で識別されます。

正規表現のパターンは名前つきもしくは番号つきのグループを含むことはできません。

リポジトリ

===========

Bazaarのリポジトリはコミットされた情報が保存される場所です。

すべてのブランチと関連づけされたリポジトリが1つ存在します。

リポジトリは一種のデータベースです。

通常、パフォーマンスのためにBzrはこれを自動的に維持しますが、ある状況(たとえば短い期間にとても多くのコミットを行う)

データベースのインデックスを最適化するようbzrに求めるとよいでしょう。

これは'bzr pack' コマンドによって行われます。

デフォルトでは 'bzr init' を実行するだけで新しいブランチの中でリポジトリが作成されますが、

同じ位置で情報を共有するために複数のブランチを許可する共用リポジトリを作成することが可能です。

新しいブランチが作成されたとき使用できる共用リポジトリが存在するかどうかを最初に確認します。

同じプロジェクトのブランチが1つのリポジトリを共有するとき、一般的にスペースが大きく節約されます。

(たとえばリポジトリの範囲内でブランチを作成するなどの)いくつかのコマンドに対してこれは大きな時間の節約になります。

共用リポジトリを作るには、init-repositoryコマンド(もしくはエイリアスのinit-repo)を使います。

このコマンドは作成するリポジトリの位置をとります。

このことは'bzr init-repository repo'によって'repo'という名前のディレクトリが作成され

その中に共用リポジトリが格納されることを意味します。

このディレクトリの中に作成された新しいブランチはストレージ用にそれを使用します。

1つ以上のプロジェクトのブランチを作成するときに1つのリポジトリを作成することはよい考えです。

これは開発を行っている作業領域と、ホスティングプロジェクト用のサーバー領域の両方にあてはまります。

後者の場合、作業ツリーなしのブランチが欲しいことは良くあります。

ブランチのファイルは直接編集されないので作業ツリー用にディスクスペースを使い切る必要はありません。

作業ブランチを持たないリポジトリを作成するには、 'init-repository'に'--no-trees'オプションを渡します。

関連コマンド::

  init-repository   共用リポジトリを作成する。

                    新しいブランチが作業ツリーを作成しないものを作成するには--no-treesを使用する。

ルール

=======

紹介

-----

ルールはiniファイルフォーマットで定義されます。

セクションはファイルのglobパターンでそれぞれのセクションの内容は

そのパターンにマッチするファイル用のプリファレンスです。例です::

    [name *.bat]

    eol = dos

    [name *.html]

    keywords = escape

これらのようなプリファレンスは選択されたブランチの中で

選択されたファイル用にカスタムのふるまいを提供したいコマンドとプラグインに役立ちます。

ファイル

---------

すべてのブランチ用のデフォルトルールはオプションの ``BZR_HOME/rules`` ファイルで定義されます。

ルールのパターン

-----------------

パターンは順序づけされ1つマッチすると共に検索は停止します。

結果として、より明確なパターンをファイルのトップの方に置くべきです。

ルールパターンは無視パターンとまったく同じ仕様を利用します。

詳細は ``bzr help patterns`` を参照してください。

注: 角かっこを含むパターンはそれらが正しく解析されるようにクォートで囲まなければなりません。

スタンドアロンのツリー

=======================

スタンドアロンのツリーは関連リポジトリを持つ作業ツリーです。

他に依存していないので、これは独立して利用できるブランチです。

(bzr initを通して)スタンドアロンのツリーの作成は

既存のプロジェクトをバージョン管理の元に置くための最も速い方法です。

関連コマンド::

  init    ディレクトリをバージョン管理下にあるブランチにする。

同期化がずれているブランチ

==========================

チェックアウト、ツリーもしくはブランチを軽量ブランチに再設定するとき、

ローカルのブランチを破壊しなければなりません。

(チェックアウトに関して、これはキャッシュとして最初に提供するローカルブランチです。)  

破壊されるブランチが同じ最終リビジョンを持たなければ、

軽量用チェックアウト用の新しい参照ブランチ、データが失われる可能性があるので、

Bazaarは拒否します。

この取り組み方は *なぜ* ブランチの同期がずれるのかによります。

チェックアウトが手元にありローカルコミットを行う場合、

"bzr update"(とおそらくは"bzr commit")を実行することで再び同期化できます。

ブランチが手元にあり、リモートブランチが時代遅れになっている場合、

"bzr push"を使用してローカルの変更をプッシュできます。

ローカルブランチが時代遅れであれば、"bzr pull"をできます。

両方のブランチに変更があれば、変更をマージ、コミットしてプッシュできます。

変更の一部が便利でなければ、"push --overwrite"もしくは代わりに"pull --overwrite"できます。

作業ツリー

===========

作業ツリーはディスク上に設置されたブランチのコンテンツなのでファイルを見て編集できます。

作業ツリーはブランチに変更を行う場所なので、

作業ツリーの現在の状態をコミットするとき、コミットに記録されるレコードです。

ブランチをリモートシステムにプッシュするとき、作業ツリーは作成されません。

ファイルがすでに存在すれば、ファイルは更新されません。

ブランチの情報は更新され作業ツリーは時代遅れとしてマークされます。

リモートの作業ツリーを更新するのは難しいです。

アンコミットされた変更が存在するもしくは更新によってリモートで扱うのが難しい内容の衝突が引き起こされるからです。

作業ツリーなしのブランチがあれば 作業ツリーを作成するために 'checkout' コマンドを使用できます。

ブランチから 'bzr checkout .' を実行すると作業ツリーが作成されます。

リモートでブランチが更新されると、そのディレクトリの中で'bzr update'を実行することで作業ツリーを更新できます。

望まない作業ツリーを持つブランチがある場合、安全であれば'remove-tree'コマンドはツリーを除外します。 

ブランチにプッシュするとき更新されないリモート作業ツリーに関する警告を回避することでこれは可能です。 

これは'--no-trees'リポジトリ('bzr help repositories'を参照)に取り組むときにも便利です。

プッシュするリモートマシン上で作業ブランチを持ちたい場合、

pushするごとにリモートブランチで'bzr update'を実行するか、

pushの間にツリーを更新する他の方法を使用できます。

rsyncを使用してpushと同じように作業ツリーを更新する'rspush'プラグインが存在します。

それぞれのプッシュの後で'bzr update'を自動的に実行する'push-and-update'プラグインも存在します。

便利なコマンド::

  checkout     ブランチが作業ツリーを持たないときにそれを作成する。

  remove-tree  これを行うときに安全であるときにブランチから作業ツリーを除外する。

  update       作業ツリーが関連ブランチから同期がずれているとき

               このコマンドによってブランチにマッチするツリーが更新される。

.. _formats: `ストレージフォーマット`_

.. _standalone-trees: `スタンドアロンのツリー`_

.. _sync-for-reconfigure: `同期化がずれているブランチ`_

.. _working-trees: `作業ツリー`_

リスト

#######

認証の設定

===========

Intent

------

``authentication.conf`` ファイルの中で多くの異なる認証ポリシーは記述できますが

特定のユーザーはすべてのブランチ用のユーザーとパスワードを指定しなくても

自分のニーズをカバーするわずかな定義だけが必要です。

このファイルの中で見つかる定義は与えられたurl用のクレデンシャルを見つけるために使われます。

一般的に同じクレデンシャルを必要とするリモートサーバーの周辺で宣言を分類することで可能な限り多くのブランチに対して

クレデンシャルを使用できます。

異なるサーバーによって使用されるクレデンシャルを宣言することも可能です。

intentは維持を最少にするためにこのファイルを可能な限り小さくするものです。

このファイルの中で関連のクレデンシャルが宣言されるとパスワード(セキュリティハザード)を埋め込まず

もしくは(他の人とURLの共有を有効にする)ユーザーなしでブランチのURLを利用できます。

次のURLよりも::

  bzr branch ftp://joe:secret@host.com/path/to/my/branch

シンプルになります::

  bzr branch ftp://host.com/path/to/my/branch

``authentication.conf`` ファイルを作成したことを前提とします::

  [myprojects]

  scheme=ftp

  host=host.com

  user=joe

  password=secret

認証の定義

-----------

bzrによってサポートされるさまざまなスキームによって使用される2種類の認証があります:

1. ユーザーとパスワード

``FTP`` は ``host`` 用に (``user`` 、 ``password``) を必要とします。

``SFTP`` は認証用にパスワードもしくはホストキーを使用できます。

しかしながら、sshエージェントはベターで、よりセキュアな解決方法です。

独自のセキュアではない方法を提供しないことにします。

2. ユーザー、領域とパスワード

ホストに対して認証するために ``HTTP`` と ``HTTPS`` は(``user, realm, password``)を必要とします。

``.htaccess`` ファイルを利用することで、たとえば、任意の ``host`` 

に対して (``user, realm, password``) をいくつか定義することが可能です。

ですので本当に必要なのは (``user``, ``password``, ``host``, ``path``)です。

``realm`` は定義で考慮されませんが、bzrにパスワードを催促される場合表示されます。

``HTTP proxy`` は適切なポートを指定することで ``HTTP`` (もしくは ``HTTPS``) として扱うことができます。

すべてのスキームを考慮するには、パスワードは認証定義の一式 (``scheme``, ``host``, ``port``, ``path``, ``user``, ``password``) から推定されます。

  * ``scheme``: 空にできます (定義の残りは任意のスキームに対して使用できることを意味する)、

    ``SFTP`` と ``bzr+ssh`` はここでは使うべきではありません。

    代わりに ``ssh`` が使われるべきです。これが認証に関して本当のスキームだからです。

  * ``host``: 空にできます (ホスト用のデフォルトとして振る舞う),

  * ``port`` は空にできます (ホストが同じスキームに対していくつかのサーバーを提供するときに便利)、

    数値の値のみが許可され、サーバーがスキームの標準ポートとは異なるポートを使用するときのみにこれは使用されます。

  * ``path``: 空にできます (FTPもしくはSFTPはこれを使用しません),

  * ``user``: 空にできます (デフォルトでは ``bzr`` はpythonの ``getpass.get_user()`` を使用),

  * ``password``: 常にパスワードをプロンプトで入力する方が望ましいのであれば空にできます。

任意のURLに対して、複数の定義を提供できます。

bzrは次のルールに従って (``user`` [, ``password``]) を選択します:

 1. 最初にマッチするものが優先される

 2. すべてにマッチする空のフィールド

 3. デコレータがリクエストされたURLに使用されていても ``scheme`` はマッチします。

 4. ``host`` は正確にマッチするか '.' で始まる場合、ドメインとしてふるまいます。

    (``project.bzr.sf.net`` は ``.bzr.sf.net`` にマッチしますが ``projectbzr.sf.net`` は ``bzr.sf.net`` にマッチしない)。

 5. ``port`` はリクエストされたURLに含まれる場合(正確にマッチする場合のみ)マッチします。

 6. ``path`` はリクエストされたURLに含まれる場合マッチします (そして上記のルール #2 によって、

    空のパスは任意の提供されたパスにマッチします)。

ファイルのフォーマット

----------------------

`設定ファイル`_ 用の一般ルールは変数ポリシー意外に当てはまります。

.. _設定ファイル: #configuration-settings

それぞれのセクションで認証の定義を記述します。

セクションの名前は任意の文字列で、 ``DEFAULT`` の値のみが保存され

*最後* のセクションとして現れます。

それぞれのセクションは次の内容を定義すべきです:

* ``user``: 使用されるログイン名

それぞれのセクションは次の内容を定義できます:

* ``host``: リモートサーバー

* ``port``: サーバーがリスンしているポート番号

* ``path``: ブランチの位置

* ``password``: パスワード

例

---

外部でホストされた個人プロジェクト

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

すべての接続は同じ ``user`` で行われ

(デフォルトのbzrのものが適切でない場合のためのリモートの接続) 

パスワードはいくつかの例外とともに常に催促されます::

        # hobby.netのPetプロジェクト

        [hobby]

        host=r.hobby.net

        user=jim

        password=obvious1234

        # ホームサーバー

        [home]

        scheme=https

        host=home.net

        user=joe

        password=1essobV10us

        [DEFAULT]

        # ローカルユーザーがbarbazで、すべてのリモートサイト上ではfoobarとして

        user=foobar

ソースホスティングプロバイダ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

shp.net(仮想)ドメインにおいて、それぞれのプロジェクトは独自のサイトを持ちます::

        [shpnet domain]

        # sftpを使用するが、sshは認証用に使用される

        scheme=ssh

        # '.' は 'shp.net' だけがマッチしないことを保証する

        host=.shp.net

        user=joe

        # bzrはsftp用のパスワードの提供を保証しません

        # パスワードをインタラクティブに入力したくなければ

        # sshエージェントを使用することを考えてください(pageant, ssh-agent、など)

HTTPS、SFTPサーバーとプロキシ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

company.comにおいて、サーバーのホスティングリリースは統合ブランチの背後にはプロキシがあり、

2つのブランチは異なる認証ポリシーを使用します::

        [reference code]

        scheme=https

        host=dev.company.com

        path=/dev

        user=user1

        password=pass1

        # devサーバー上の開発ブランチ

        [dev]

        scheme=ssh # bzr+sshとsftpはここで利用可能

        host=dev.company.com

        path=/dev/integration

        user=user2

        # プロキシ

        [proxy]

        scheme=http

        host=proxy.company.com

        port=3128

        user=proxyuser1

        password=proxypass1

計画的な強化

-------------

次の内容はまだ実装されていませんが進行中の作業の一部として計画されています:

* ``password_encoding`` フィールドの追加は次のとおりです:

  - さまざまな難読化のエンコーディング(たとえばbase64)でパスワードを保存する。

  - パスワードの保存をプラグインに委譲する(たとえば.netrc)。

* ユーザーがユーザー名もしくはパスワードの入力を催促されたらクレデンシャルを更新する。

* ``HTTPS`` 用に ``verify_certificates`` フィールドを追加する。

``password_encoding`` と ``verify_certificates`` フィールドは認識されますが

実際の実装では無視されます。

バグトラッカーの設定

=====================

コミットを行うとき、その変更によって修正されたバグに関するメタデータは --fixes オプションを使用することで記録されます。

それぞれのバグが修正されたものとしてマークされるために、エントリーが '<url> <status>' を述べる 'bugs' リビジョンプロパティに含まれます。

(現在サポートされる ``status`` の値は ``fixed.`` だけです)

Launchpadの中心バグトラッカー用のサポートは組み込まれています。

他のバグトラッカーに関して、正しいURLが記録されるように設定が予め要求されます。

Launchpadに加えて、BazaarはBugzillaとTracに適切なURLの生成を直接サポートします。

プロジェクトが異なるバグトラッカーを使用するのであれば、そのサポートを追加するのは簡単です。

BugzillaもしくはTracを使用しているのであれば、

バグトラッカーの基底URLを格納する設定変数を設定することだけが必要です。

これらのオプションは ``bazaar.conf`` 、 ``branch.conf`` もしくは ``locations.conf`` のブランチ固有のセクションに入ります。

取り組むプロジェクトごとにこれらの値をセットアップできます。

注: それぞれのトラッカーに対して短縮名を提供するのであれば、望むのであればコミット時に1つもしくは複数のトラッカーで1つもしくは複数のバグを指定できます。

Launchpad

---------

バグ2を修正するコミットを記録するには ``bzr commit --fixes lp:2`` を使用します。

bugzilla_<tracker_abbreviation>_url

-----------------------------------

存在するのであれば、Bugzillaのバグトラッカーの位置は <tracker_abbreviation> によって参照されます。

そのバグトラッカーのバグをそのコミットで修正されたものとしてマークするためにはこのオプションは ``bzr commit --fixes`` と一緒に使用できます::

    bugzilla_squid_url = http://www.squid-cache.org/bugs

上記の例はSquidのバグ 1234が修正されたものとしてマークするために ``bzr commit --fixes squid:1234`` を許可します。

trac_<tracker_abbrevation>_url

------------------------------

存在するのであれば、Tracインスタンスの位置は <tracker_abbreviation> によって参照されます。

そのコミットによってバグが修正されたものとしてそのトラッカーの中でマークするためにこのオプションは ``bzr commit --fixes`` と一緒に使用できます::

    trac_twisted_url = http://www.twistedmatrix.com/trac

上記の例はTwistedのバグ1234を修正したものとしてマークするために ``bzr commit --fixes twisted:1234`` を許可します。

bugtracker_<tracker_abbrevation>_url

------------------------------------

存在するのであれば、一般的なバグトラッカーのインスタンスの位置は <tracker_abbreviation> によって参照されます。

位置は ``{id}`` プレースホルダーを含まなければなりません。プレースホルダーは特定のバグIDに置き換えられます。

そのコミットによってバグが修正されたものとしてそのトラッカーでマークするためにこのオプションを ``bzr commit --fixes`` と一緒に使用できます::

    bugtracker_python_url = http://bugs.python.org/issue{id}

上記の例はPythonのRoundupバグトラッカーのバグ1234を修正されたものとしてマークするために ``bzr commit --fixes python:1234`` を許可します::

    bugtracker_cpan_url = http://rt.cpan.org/Public/Bug/Display.html?id={id}

上記はCPANのRTバグトラッカー用です。

.. _configuration-settings:

構成設定

=========

.. TODO: Should have some explanation of why you'd want things in

.. branch.conf.

環境変数の設定

---------------

大抵の設定が設定ファイルによって取り扱われる一方で、

半永久的ないくつかのオプションは環境変数を通して制御できます。

BZR_EMAIL

~~~~~~~~~

Bazaarによって使用されるEメールのIDを上書きする。よくあるフォーマット::

  "John Doe <jdoe@example.com>"

``email`` の設定値も参照してください。

BZR_PROGRESS_BAR

~~~~~~~~~~~~~~~~

進行状況の表示方法を上書きする。可能な値は "none"、 "dots"、 "tty"

BZR_SIGQUIT_PDB

~~~~~~~~~~~~~~~

SIGQUITが通常とおりに振る舞うようにするかもしくはブレークインデバッガーを起動するかどうか制御する。

* 0 = 標準のSIGQUITのふるまい(通常はコアダンプを伴ってexitする)

* 1 = ブレークインデバッガーを起動する (デフォルト)

BZR_HOME

~~~~~~~~

Bazaarによって使用されるホームディレクトリを上書きする

BZR_SSH

~~~~~~~

異なるSSHの実装を選択する。

BZR_PDB

~~~~~~~

デバッガもしくはエラーを立ち上げるか制御する。

* 0 = Standard behavior

* 1 = Launch debugger

BZR_REMOTE_PATH

~~~~~~~~~~~~~~~

bzr+sshプロトコルを使用する際に使用するBazaar実行ファイルへのパス。

設定値 ``bzr_remote_path`` も参照。

BZR_EDITOR

~~~~~~~~~~

コミットメッセージなどの際にBazaarが使用するエディタへのパス。

BZR_PLUGIN_PATH

~~~~~~~~~~~~~~~

Bazaarが使用するプラグインディレクトリへのパス。

BZRPATH

~~~~~~~

Bazaarがシェルシェルプラグインの外部コマンドを探すパス。

設定ファイル

-------------

設置場所

~~~~~~~~~

設定ファイルはLinux/Unixの場合 ``$HOME/.bazaar`` に

Windowsの場合 ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` に設置されます。

( ``bzr version`` を使用することでシステムに設置された位置をチェックできます)

この位置に3つの主要な設定ファイルが存在します:

* ``bazaar.conf`` はデフォルトの設定オプションを記述します

* ``locations.conf`` は特定のブランチの位置用の設定情報を記述します。

* ``authentication.conf`` はリモートサーバー用のクレデンシャル情報を記述します。

それぞれのブランチはそのブランチに固有な値を設定する設定ファイルも格納します。

このファイルはブランチの範囲内の ``.bzr/branch/branch.conf`` で見つかります。

このファイルはブランチのすべてのユーザーに見えます。

あなたのブランチ専用に設定値の1つを上書きしたいのであれば、 ``locations.conf`` で行うことができます。

一般的なフォーマット

~~~~~~~~~~~~~~~~~~~~

iniファイルは3つの種類のコントラクト: セクションヘッダー、セクション変数とコメントを持ちます。

コメント

^^^^^^^^^

コメント行は "#" で始まります("hash mark", "pound sign"  "number sign"とも呼ばれます)。

コメント行はiniファイルを解析するときBazaarによって無視されます。

セクションヘッダー

^^^^^^^^^^^^^^^~~~~

セクションヘッダーは行頭から始まり角かっこで囲まれた単語です。

典型的なセクションヘッダーは次のとおりです::

    [DEFAULT]

bazaar.confに対して現時点で唯一有効なセクションヘッダーは[DEFAULT]と[ALIASES]です。

セクションヘッダーは大文字と小文字を区別します。

デフォルトのセクションが提供する設定変数はブランチの設定ファイルで上書きできます。

``locations.conf`` に対して、

セクションにマッチする最長のものを持つセクションからの変数は潜在的に有効な別のセクションヘッダーを除外するために使われます。

セクションヘッダーはブランチ用のパスをセクションヘッダーとして使用します。次のような例があります::

    [http://mybranches.isp.com/~jdoe/branchdir]

    [/home/jdoe/branches/]

セクション変数

^^^^^^^^^^^^^^^

セクション変数はセクションの範囲に属します。セクション変数は変数名、等号と値を格納します。例です::

    email            = John Doe <jdoe@isp.com>

    check_signatures = require

変数のポリシー

^^^^^^^^^^^^^^^

セクションの中で定義された変数は名前つきのディレクトリもしくはURLに加えてそれらを格納する位置にも影響を与えます。

ポリシーは可変変数が含まれる位置のために解釈される方法を変更するために使用できます。現在は3つのポリシーが利用できます:

 none:

   値は含まれる位置に対して同じように解釈されます。

   これはデフォルトのふるまいです。

 norecurse:

   値はセクション名によって指定された正確な位置のみに対して使用されます。

 appendpath:

   for contained locations, 追加パスのコンポーネントは値に追加されます。

ポリシーは "$var:policy" 形式の名前を持つキーによって指定されます。

たとえば、ブランチのツリー用のpushの位置を定義するには、次の設定が使われます::

  [/top/location]

  push_location = sftp://example.com/location

  push_location:policy = appendpath

この設定によって、 ``/top/location/branch1`` 用のpush位置は ``sftp://example.com/location/branch1`` になります。

主要な設定ファイルのbazaar.conf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``bazaar.conf`` は ``[DEFAULT]`` と呼ばれる1つのセクションだけを許可します。

このデフォルトセクションはすべてのブランチ用のデフォルト設定オプションを格納します。

デフォルトセクションは ``locations.conf`` にブランチ固有のセクションを提供することで上書きできます。

典型的な ``bazaar.conf`` セクションは次のようになります::

    [DEFAULT]

    email             = John Doe <jdoe@isp.com>

    editor            = /usr/bin/vim

    check_signatures  = check-available

    create_signatures = when-required

ブランチの位置の設定ファイルのlocations.conf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``locations.conf`` によって特定のブランチ用に設定を上書きできます。

フォーマットは1つの重大な変更を伴うbazaar.confのデフォルトセクションに対してほとんど理想的です: 

デフォルトを記述する代わりに、セクションヘッダーは値を上書きしたいブランチへのパスになります。

ワイルドカードの '?' と '*' がサポートされます::

    [/home/jdoe/branches/nethack]

    email = Nethack Admin <nethack@nethack.com>

    [http://hypothetical.site.com/branches/devel-branch]

    create_signatures = always

    check_signatures  = always

    [http://bazaar-vcs.org/bzr/*]

    check_signatures  = require

認証用の設定ファイル、authentication.conf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``authentication.conf`` によってリモートサーバー用のクレデンシャルを指定できます。

これはすべてのサポートされる転送と認証(たとえばsmtp)を必要とするbzrの一部に対して使用できます。

ファイルの構文は適用しない変数ポリシー用の他の例外を除いて同じルールに従います。

設定ファイルにおける認証の使い方の詳細な情報に関しては `認証の設定`_ を参照してください。

変数の共通オプション

---------------------

email

~~~~~

Eメールアドレスはブランチをコミットする際に使われます。よく次のような形式をとります::

    email = Full Name <account@hostname.tld>

editor

~~~~~~

コミットメッセージなしで *bzr commit* が実行された場合に使用されるエディタのパスです。

この設定は環境変数 ``BZR_EDITOR`` によって設定され、

環境変数 ``VISUAL`` と ``EDITOR`` によって上書きされます。

check_signatures

~~~~~~~~~~~~~~~~

署名用のふるまいを定義します。

require

    リビジョン用のgnupg署名が存在して有効でなければなりません。

ignore

    リビジョンのgnupgの署名をチェックしない。

check-available

    (デフォルト) リビジョン用のgnupgの署名が存在する場合、それらをチェックします。

    わるい署名であることが分かるとBazaarは失敗しますが、署名が存在しない場合は失敗しません。

create_signatures

~~~~~~~~~~~~~~~~~

リビジョン署名のふるまいを定義します。

always

    コミットされるすべての新しいリビジョンに署名する。

when-required

    (デフォルト) ブランチが署名つきのリビジョンを要求するときのみ新しくコミットされたリビジョンに署名する。

never

    ブランチが署名を要求する場合でも新しくコミットされたリビジョンに署名するのを拒否する。

recurse

~~~~~~~

``locations.conf`` でのみ便利です。

このセクション用の設定をサブディレクトリにも適用するかどうか定義します:

true

    (デフォルト このセクションはサブディレクトリにも適用される。

false

    このセクションはこのディレクトリのブランチのみに適用されその下のブランチには適用されない。

gpg_signing_command

~~~~~~~~~~~~~~~~~~~

(デフォルト: "gpg"). リビジョンの署名とチェックのために使用されるプログラム。例です::

    gpg_signing_command = /usr/bin/gnpg

bzr_remote_path

~~~~~~~~~~~~~~~

(デフォルト: "bzr").  bzr用のスマートサーバーを稼働させるために使われるコマンドへのパス。

この値はlocations.confでのみ指定が許可されます。理由は次のとおりです:

- branch.confがアクセスできる前に必要だから

- セキュリティリスクになるコマンドを指定するためにリモートのbranch.confファイルを許可するから

これはBZR_REMOTE_PATH 環境変数によって上書きされます。

smtp_server

~~~~~~~~~~~

(デフォルト: "localhost")。たとえば ``merge-directive --mail-to`` 、もしくはbzr-emailプラグインによって

BazaarがEメールを送信する必要があるときに使用するSMTPサーバー、

smtp_username, smtp_password

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SMTPサーバーで認証するユーザーとパスワード。

smtp_usernameが設定されていて、smtp_passwordが設定されていなければ、Bazaarはパスワードを催促します。

Eメールを送信するためにSMTPサーバーが認証を必要とする場合のみこれらの設定が必要です。

mail_client

~~~~~~~~~~~

マージリクエストを送信するために使うメールクライアント。

デフォルトでは、Windowsではbzrは ``mapi`` を使うことを試みます。

他のプラットフォームでは、 ``xdg-email`` を試みます。

これらのどちらかが失敗すると、 ``editor`` に戻ります。

特定のクライアント用のサポートされた値:

:claws: Clawsを使用する。ファイル添付のダイアログはスキップする。

:evolution: Evolutionを使用する

:kmail: KMailを使用する

:mutt: Muttを使用する

:thunderbird: Mozilla ThunderbirdもしくはIcedoveを使用する。Thunderbird/Icedove 1.5に関して、

    これはxdg-emailが扱えないいくつかのバグに対処します。

サポートされる一般的な値は次のとおりです:

:default: 上記を参照。

:editor: マージリクエストを書くエディタを使用します。

    これはコミットID( ``bzr whoami`` を参照), 

    smtp_serverと(オプションで)smtp_usernameとsmtp_passwordも使用します。

:mapi: Windowsで好きなメールクライアントを使用します。

:xdg-email: 好きなメールプラグラムを実行するためにxdg-emailを使用する

submit_branch

~~~~~~~~~~~~~

現在の作業内容を投稿しようとしているブランチ。

これは ``bzr send`` によって自動的に設定され ``submit:`` リビジョンスペックにも使用されます。

通常、これはブランチ単位ロケーション単位で設定されます。

public_branch

~~~~~~~~~~~~~

このブランチの公開されアクセス可能なバージョン

(このブランチが公開されてアクセス可能ではないことを暗示する)。

``bzr send`` によって使用されます(そして設定されます)。

ブランチ特有のオプション

-------------------------

これらのオプションは ``dirstate-tags`` もしくは後のフォーマットを使用するブランチにのみ適用します。

通常これらは自動的に ``.bzr/branch/branch.conf`` 設定される

もしくは手動で ``locations.conf`` もしくは ``bazaar.conf`` に設定されます。

append_revisions_only

~~~~~~~~~~~~~~~~~~~~~

"True"に設定されていればリビジョンはログにのみ追加され、削除されません。

この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。

通常これは ``bzr init --append-revisions-only`` によって設定されます。

parent_location

~~~~~~~~~~~~~~~

存在すれば、pullもしくはmerge用のデフォルトブランチの位置。

通常このオプションは ``pull --remember`` もしくは ``merge --remember`` によって設定されます。

push_location

~~~~~~~~~~~~~

存在すれば、push用のデフォルトブランチの位置。

通常このオプションは ``push --remember`` によって設定されます。

bound_location

~~~~~~~~~~~~~~

チェックアウトとして振る舞うときコミットが向かう位置。

通常このオプションは ``bind`` によって設定されます。

bound

~~~~~

"True"に設定されていると、ブランチはチェックアウトとしてふるまい、bound_locationにそれぞれのコミットをpushします。

通常このオプションは ``bind``/``unbind`` に設定されます。

衝突のタイプ

=============

オペレーションの中には、merge、revertとpullのように、作業ツリーの内容を修正するものがあります。

これらの修正はプログラムで生成されるので、作業ツリーの現在の状態と衝突することがあります。

多くの種類の変更はプログラムで結合できますが、 正しいことを行われているか時々人間だけしか判断できないことがあります。

これが起きるとき Bazaarはあなたに衝突が存在するのでそれを解消するように伝えます。

Bazaarに衝突が解消したことを伝えるコマンドは ``resolve`` ですが、

これを実行できる前にいくつかのアクションを実行しなければなりません。

それぞれの衝突は下記のセクションで説明され、衝突を解消するために行わなければならないアクションの概要が説明されています。

テキストの衝突

---------------

典型的なメッセージは次のとおりです::

  Text conflict in FILE

テキストのマージが2つのセットのテキストの変更を完全に折り合いをつけられないときにこれらは生み出されます。

BazaarはTHIS、OTHER、とBASEのエクステンションでそれぞれのバージョン用にファイルをemitします。

THISはターゲットツリーからのファイルのバージョン、すなわち、変更をマージしようとしているツリーです。

OTHERはターゲットにマージしようとしているバージョン、BASEは比較用のベースとして使われる古いバージョンです。

ファイルのメインコピーにおいて、Bazaarは調整できるすべての変更を含み、

未調整の衝突は ``<<<<<<<`` のように "herringbone" マーカーによって囲まれます。

たとえば、初期のテキストが "The project leader released it."、でTHISはこれを "Martin Pool released it." に修正する一方で、

OTHERは"The project leader released Bazaar."に修正します。衝突は次のようになります::

  <<<<<<< TREE

  Martin Pool released it.

  =======

  The project leader released Bazaar.

  >>>>>>> MERGE-SOURCE

正しい解消方法は"Martin Pool released Bazaar."になります。

ファイルのメインコピーを編集する、もしくはTHIS、OTHERとBASEバージョン上で外部ツールを起動することのどちらかでテキストの衝突を扱うことができます。

テキストの衝突の解消において他のものから変更のセットの1つの選別はめったにないことは言っておく価値があります。

より頻繁に、2つのセットの変更はインテリジェントに結合しなければなりません。

メインコピーを編集するとき、 herringbone マーカーを必ず削除してください。

編集作業を終えたとき、ファイルは衝突がけっして起こらないようであれば、コミットする準備ができています。

テキストの衝突を解消したとき、"bzr resolve"を実行するだけでBazaarは解消した衝突を自動検出します。

内容の衝突

----------

典型的なメッセージ::

  Contents conflict in FILE

ターゲットツリーとマージソースの中の変更の衝突が存在するときにこの衝突は起こりますが、

が衝突したアイテムはテキストファイルではありません。

これらはバイナリファイルもしくはシンボリックリンクもしくはディレクトリになります。

片方が削除され、もう一方が修正されたファイルでも起こり得ます。

テキストの衝突のように、BazaarはTHIS、OTHER とBASEファイルをエミットしますが

(これらは通常のファイル、シンボリックリンクもしくはディレクトリになります)、

これはherringbone衝突マーカーを持つファイルの"メインコピー"を含みません。

"メインコピー"がTHISもくはOTHERにリネームされたときにこれは現れます。

これを解消するには、ファイルを通常の名前に戻すために "bzr mv" を使用し変更を手動で結合します。

満足したときに、 "bzr resolve FILE" を実行します。この種の衝突が解消されたときにBazaarは自動検出できません。

重複したパス

-------------

典型的なメッセージ::

  Conflict adding file FILE.  Moved existing file to FILE.moved.

時々Bazaarはすでに使用されているパス名を用いてファイルを作成しようとします。

既存のファイルは "FILE.moved" にリネームされます。

望むのであれば、これらのファイルの1つをリネームするか、それらの内容を結合できます。

満足したら、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行できます。

バージョン管理下にない親

-------------------------

典型的なメッセージ::

    Conflict because FILE is not versioned, but has versioned children.

ときどきBazaarは親ディレクトリがバージョン管理されていないファイルを作成しようとします。

ターゲットの中でディレクトリが削除されたときにこれが起こりますが、

ソースの中の新しい子を持ちます。逆も同様です。

この状況において、Bazaarは親ディレクトリも同様にバージョン管理します。

この問題の解決方法は特定のシナリオに大きく依存します。

ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。

満足したら、衝突を解消したものとして"bzr resolve FILE"を実行できます。

見つからない親

---------------

典型的なメッセージ::

  Conflict adding files to FILE.  Created directory.

ターゲットの中でファイルを削除するときにこれが起こりますが、ソースの中に新しい子があります。

これは "unversioned parent" の衝突と似ています。

バージョン管理を解除される代わりに、親ディレクトリが *存在しない* ことを除いて、

この状況において、Bazaarは見つからない親を作成します。

この問題の解決方法は特定のシナリオに大いに依存します。

ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。

満足したら、衝突を解消したものとして "bzr resolve FILE" を実行できます。

親を削除する

------------

典型的なメッセージ::

  Conflict: can't delete FILE because it is not empty.  Not deleting.

これは"見つからない親"の反対です。ソースの中でディレクトリは削除されますが、

ターゲットの中で新しい子はあります。Bazaarはディレクトリを保有し続けます。

この問題の解消は特定のシナリオに大いに依存します。

ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。

満足したら、衝突を解消したものとしてマークするために"bzr resolve FILE"を実行できます。

パスの衝突

-----------

典型的なメッセージ::

  Path conflict: PATH1 / PATH2

ソースとターゲットがファイルの名前もしくは親ディレクトリを修正したときに起こります。

Bazaarはソースからパス要素を使用します。

ファイルをリネームできれば、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。

親のループ

-----------

典型的なメッセージ::

  Conflict moving FILE into DIRECTORY.  Cancelled move.

ソースとターゲットがそれぞれディレクトリを移動させたので、

変更が適用可能であれば、ディレクトリはそれ自身を含むときにこれは起こります。

例です::

  $ bzr init

  $ bzr mkdir a

  $ bzr mkdir b

  $ bzr commit -m "BASE"

  $ bzr branch . ../other

  $ bzr mv a b

  $ bzr commit -m "THIS"

  $ bzr mv ../other/b ../other/a

  $ bzr commit ../other -m "OTHER"

  $ bzr merge ../other

この状況において、Bazaarは移動をキャンセルして、"a"を"b"の中に残しておきます。

望むのであればディレクトリをリネームできれば 

衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。

ディレクトリではない親

-----------------------

典型的なメッセージ::

  Conflict: FILE.new is not a directory, but has files in it.

  Created directory.

片方がファイルをディレクトリを追加したとき、もう一方がディレクトリをファイルもしくはシンボリックリンクに変更したときにこれは起きます。

例です::

  $ bzr init

  $ bzr mkdir a

  $ bzr commit -m "BASE"

  $ bzr branch . ../other

  $ rmdir a

  $ touch a

  $ bzr commit -m "THIS"

  $ bzr mkdir ../other/a/b

  $ bzr commit ../other -m "OTHER"

  $ bzr merge ../other

MalformedTransform

-------------------

Bazaarに例外のMalformedTransformを起動させること可能です(非常にまれですが)。

これはBazaarが解決できないファイルシステムの衝突に遭遇したことを意味します。

通常これはバグを示します。これに遭遇したら教えて頂くようお願いします。

バグトラッカーは https://launchpad.net/bzr/+bugs です。

現在のストレージフォーマット

============================

:pack-0.92:

    (ネイティブ) (デフォルト) 0.92で新しく導入: 

    dirstate-tagsフォーマットリポジトリと互換性のあるデータを持つパックベースのフォーマット。

    0.92以前のbzrリポジトリと相互運用できますが0.92以前のbzrでは読めません。

    以前はknitpack-experimentalと呼ばれていました。詳細な情報に関しては、

    http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。

:1.6:

    (ネイティブ) スタックをサポートするディレクトリに基づいたブランチとパック。

:1.6.1-rich-root:

    (ネイティブ) スタックとリッチrootデータをサポートするブランチとパックベースのリポジトリ(bzr-svnが必要)

:1.9:

    (ネイティブ) btreeインデックスを使用するブランチとパックベースのリポジトリ。

:1.9-rich-root:

    (ネイティブ) btreeインデックスとrich rootデータを使用する

    ブランチとパックベースのリポジトリ(bzr-svnに必要)。

ストレージフォーマットは ``bzr help formats`` を参照。

環境変数

========

================ =================================================================

BZRPATH          bzrがシェルプラグインコマンドを探すパス。

BZR_EMAIL        ユーザーのEメールアドレス。EMAILを上書きする。

EMAIL            ユーザーのEメールアドレス。

BZR_EDITOR       コミットメッセージの編集用エディタ。EDITORを上書きする。

EDITOR           コミットメッセージの編集用エディタ

BZR_PLUGIN_PATH  bzrがプラグインを探すパス。

BZR_HOME         .bazaarの設定ディレクトリを保持するディレクトリ。HOMEを上書きする。

BZR_HOME (Win32) bazaar設定ディレクトリを保持するディレクトリ。APPDATAとHOMEを上書きする。

BZR_REMOTE_PATH  リモート'bzr'コマンドのフルネーム(bzr+ssh:// URL用).

BZR_SSH          SSHクライアント: paramiko (デフォルト), openssh, ssh, plink.

BZR_LOG          .bzr.logの位置(ロギングを停止するには'/dev/null'を使う)。

BZR_LOG (Win32)  .bzr.logの位置(ロギングを停止するには'NUL'を使う)。

================ =================================================================

ファイル

========

:On Linux:   ~/.bazaar/bazaar.conf

:On Windows: C:\\Documents and Settings\\username\\Application Data\\bazaar\\2.0\\bazaar.conf

ユーザーのデフォルト設定は上記のとおりです。

``[DEFAULT]`` セクションすべての場所に適用される一般的な設定を定義するために使用できます。

``[ALIASES]`` セクションは共通に使用されるオプション用のコマンドエイリアスを作成するために使用できます。

典型的な設定ファイルは次のとおりです::

  [DEFAULT]

  email=John Doe <jdoe@isp.com>

  [ALIASES]

  commit = commit --strict

  log10 = log --short -r -10..-1

グローバルオプション

=====================

これらのオプションは任意のコマンドで使用可能で、コマンドの前で入力します(たとえば"bzr --profile help")。

--version      バージョン番号を表示する。コマンドの前に入力しなければならない。

--no-aliases   このコマンドを実行する際にコマンドエイリアスを処理しない。

--builtin      プラグインのコマンドではなく、組み込みのコマンドを使用する。

               このオプションは他のプラグインの効果を抑制しない。

--no-plugins   プラグインを処理しない。