Bazaarユーザーリファレンス ¶

Version:	1.11
Generated:	2009-01-09

Contents

Bazaarユーザーリファレンス

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

このマニュアルは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       作業ツリーが関連ブランチから同期がずれているとき
             このコマンドによってブランチにマッチするツリーが更新される。

リスト ¶

認証の設定¶

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種類の認証があります:

ユーザーとパスワード

FTP は host 用に (user 、 password) を必要とします。 SFTP は認証用にパスワードもしくはホストキーを使用できます。しかしながら、sshエージェントはベターで、よりセキュアな解決方法です。独自のセキュアではない方法を提供しないことにします。

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

ホストに対して認証するために 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]) を選択します:

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

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

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

host は正確にマッチするか ‘.’ で始まる場合、ドメインとしてふるまいます。 (project.bzr.sf.net は .bzr.sf.net にマッチしますが projectbzr.sf.net は bzr.sf.net にマッチしない)。

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

path はリクエストされたURLに含まれる場合マッチします (そして上記のルール #2 によって、空のパスは任意の提供されたパスにマッチします)。

ファイルのフォーマット¶

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

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

セクションの名前は任意の文字列で、 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バグトラッカー用です。

構成設定¶

環境変数の設定¶

大抵の設定が設定ファイルによって取り扱われる一方で、半永久的ないくつかのオプションは環境変数を通して制御できます。

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 です。

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

1.6.1-rich-root:
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:	(ネイティブ) スタックをサポートするディレクトリに基づいたブランチとパック。
	(ネイティブ) スタックとリッチ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`	プラグインを処理しない。
`--profile`	ホットスポットプロファイラを使用するプロファイルの実行。
`--lsprof`	lsprofプロファイラを使用したプロファイルの実行。
`--lsprof-file`	lsprofプロファイラを使用するプロファイルを実行し、結果を指定ファイルに書き込む。ファイル名が”.txt”で終わる場合, テキストフォーマットが使用されます。ファイル名が”callgrind.out”で始まる、もしくは”.callgrind”で終わる場合、 KCacheGrind用に出力がフォーマットされる。さもなければ、出力はpickleになる。
`--coverage`	指定ディレクトリの行カバレージレポートを生成する。

プロファイリングに関する詳細な情報はdoc/developers/profiling.txtを参照してください。トラブルシューティングと開発を手助けするためのたくさんのデバッグフラッグも利用可能です。

`-Dauth`	使用される認証セクションをトレースする。
`-Derror`	通常のエラーハンドリングの代わりに、常にエラー上のトラックバックを表示する。
`-Devil`	割高なもしくはわるいスケーリングオペレーションを行うコールサイトをキャプチャする。
`-Dfetch`	リポジトリ間のコピーの履歴をトレースする。
`-Dhashcache`	ハッシュを決定するために作業ファイルが読み込まれるたびにログを記録する
`-Dhooks`	フックの実行をトレースする。
`-Dhpss`	スマートプロトコルリクエストとレスポンスをトレースする。
`-Dhttp`	http接続、リクエストとレスポンスをトレースする。
`-Dindex`	主要なindexオペレーションをトレースする。
`-Dknit`	knitオペレーションをトレースする。
`-Dlock`	lockdirロックがとられるもしくはリリースされるときをトレースする。
`-Dmerge`	マージのデバッグ用の情報を表示する。
`-Dpack`	packオペレーション用の情報を表示する。

フック¶

紹介¶

yyy クラスの xxx タイプのフックを使用するには登録する必要があります:

yyy.hooks.install_named_hook("xxx", ...)

例に関してはユーザーガイドのフックを利用するを参照してください。

それぞれのフックが含むクラスは下記のそれぞれのフックタイプの後で丸かっこの中で示されます。

それぞれの説明ではクライアント(bzrが実行されるマシン)もしくはサーバー (ブランチURLで示されるマシン)で実行されるか示します。これらは必ずしも同じマシンではありません。

以下の1つがtrueの場合(フックを含む)プラグインはサーバー上で実行されます:

リモートブランチがクライアントと同じマシン上にあり、クライアントはプラグインを有効にしている。

接続はスマートサーバー経由で行われ(“bzr://”、”bzr+ssh://”もしくは”bzr+http://”で始まるURLでアクセスするもしくはスマートサーバーがHTTP経由で利用可能なときに “http://”でアクセスする)、サーバーがプラグインを有効にしている。

open (Branch)¶

Branchオブジェクトが開いた後で、Branchオブジェクトによって呼び出されます。クライアントとサーバーで実行します。

post_push (Branch)¶

push が完了した後で実行されます。クライアントで実行します。

フックのシグネチャは (push_result) でメンバーを含みます。

source_branch

データがpushされる場所(読み込みはロックされる)。これは最も低いレイテンシブランチになります。

target_branch

データが送信される直接の場所(書き込みがロックされる)。

master_branch

target_branch、もしくはターゲットがバインドされたブランチの場合、これはマスターロケーションになります(書き込みはロックされる)。

local_branch

ターゲットがバインドされたブランチの場合、これがターゲットブランチになる、そうでなければ、Noneになります。

old_revno

push以前のブランチのリビジョン番号(たとえば10)。

old_revid

push以前のリビジョンid (たとえば joe@foo.com-1234234-aoeua34)。

new_revno

push後のブランチのリビジョン番号(たとえば12)。

new_revid

push後のリビジョンid (たとえば joe@foo.com-5676566-boa234a)

post_pull (Branch)¶

pull が完了し後で実行されます。

フックのシグネチャは (push_result) で次のメンバーを含みます: (source, local, master, old_revno, old_revid, new_revno, new_revid)。 localはローカルのターゲットブランチもしくはNoneで、 masterはターゲットのマスターブランチで、残りは見たとおりです。 sourceでは読み込みがロックされターゲットブランチでは書き込みがロックされます。 sourceはローカルの低レイテンシブランチになります。

start_commit (MutableTree)¶

commit が作業ツリーの処理を始める前に作業ツリー上で実行されます。クライアントで実行します。

pre_commit フック(下記を参照)とは異なり、 start_commit フックは作業ツリーを安全に変更できます。

フックのシグネチャはツリーがMutableTreeオブジェクトである場所(ツリー)です

pre_commit (Branch)¶

commit が完了する前に実行されます。クライアントで実行します。

フックのシグネチャは (local, master, old_revno, old_revid, future_revno, future_revid, tree_delta, future_tree)です。 old_revnoはブランチに最初にコミットするためのNULL_REVISIONで、 tree_deltaは基底リビジョンからの変更を記述するTreeDeltaオブジェクトで、 future_treeはインメモリツリーでCommitBuilder.revision_tree()から得られます。フックはtree_deltaとfuture_treeを修正する 必要はありません 。

post_commit (Branch)¶

commit が完了した後で実行されます。クライアントで実行します。

フックのシグネチャは (local, master, old_revno, old_revid, new_revno, new_revid)です。 old_revidはブランチへの最初のコミットのためのNULL_REVISIONです。

post_uncommit (Branch)¶

uncommit が完了した後で実行されます。

apiのシグネチャは (local, master, old_revno, old_revid, new_revno, new_revid)です。 localはローカルブランチもしくはNoneで、masterはターゲットブランチで、空のブランチは0のnew_revno、Noneのnew_revidを受け取ります。

pre_change_branch_tip (Branch)¶

ブランチの書き込みがロックされている間に、ブランチチップが変更される前に実行されます。クライアントとサーバーで実行します。 push、pull、commitとuncommitのすべてはこのフックを起動させることに注意してください。

フックのシグネチャは (params) で、paramsはメンバーを含むオブジェクトです。

branch

チップが変更されるブランチ。

old_revno

変更前のブランチのリビジョン番号(たとえば10)。

old_revid

変更前のリビジョンid (たとえば joe@foo.com-1234234-aoeua34)。

new_revno

変更後のブランチのリビジョン番号(たとえば12)。

new_revid

変更後のリビジョンid (たとえば joe@foo.com-5676566-boa234a)。

ヘッドリビジョンはドットつきのリビジョン番号をけっして持たないので、old_revnoとnew_revnoメンバーは整数です。

post_change_branch_tip (Branch)¶

ブランチの書き込みがまだロックされている間にブランチのチップが変更された後に実行されます。クライアントとサーバーで実行します。 push、pull、commitとuncommitすべてがこのフックを起動させることに注意してください。

フックシグネチャは(params)で、paramsは次のメンバーを含むオブジェクトです。

branch

チップが変更されるブランチ。

old_revno

変更前のブランチのリビジョン番号 (たとえば10)。

old_revid

変更前のリビジョンid(たとえば joe@foo.com-1234234-aoeua34)。

new_revno

変更後のブランチのリビジョン番号(たとえば12)。

new_revid

変更後のリビジョンid(たとえば joe@foo.com-5676566-boa234a)。

ヘッドリビジョンはドットつきのリビジョン番号をけっして持たないのでold_revnoとnew_revnoメンバーは整数です。

set_rh (Branch)¶

注意: このフックは廃止され近い将来の内に削除されます。代わりに post_change_branch_tip フックを使用してくださるようお願いします。

transform_fallback_location (Branch)¶

スタックドブランチとして起動させ、フォールバックロケーションをアクティベイトします。

フックのシグネチャは(branch, url)です:

branch

開いたブランチ。まだフォールバックロケーションがアクティベイトされなければ、ブランチは半分ビルドされたものとして扱われることに注意してください。

url

フォールバックロケーション用にブランチが指定されたURL。フックはフォールバックロケーションを含むブランチのためにURLを返さなければなりません。複数のフックが登録されていると、呼び出される順番は未定義で変更の影響を受けます。

(1.9の新しい機能)

server_started (SmartTCPServer)¶

サーバーがディレクトリのサービスを提供始めるたびに起動します。サーバーで実行されます。フックのシグネチャは (backing urls, public url)です。

backing_url

サーバー固有のディレクトリの位置を渡す(string) URLのリスト。

public_url

ディレクトリ用の公開URL。

server_stopped (SmartTCPServer)¶

サーバーがディレクトリの提供を停止するときに常に起動します。サーバーで実行します。フックのシグネチャは server_started と同じです。

lock_acquired (LockDir)¶

ロックの取得が成功したときにLockResultオブジェクトで呼び出されます(1.8で導入)。

lock_released (LockDir)¶

ロックのリリースが成功したときにLockResultオブジェクトで呼び出されます(1.8で導入)。クライアントで実行します。

commit_message_template (msgeditor)¶

コミットメッセージテンプレートを生成するためにコミットによって起動する。それぞれのフックはコミットメッセージテンプレートを修正できます。フックのシグネチャは (commit, start_message)です:

commit

進行中のコミットのための、コミットオブジェクト

start_message

オリジナルのコミットメッセージで、初期はNone。

フックは新しいコミットメッセージテンプレートを返します。

(1.10の新しい機能)

その他のストレージフォーマット¶

実験的なフォーマットは次のとおりです。

1.12-preview-rich-root:
1.12-preview:	(ネイティブ) ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
	(ネイティブ) rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)。
development:	(ネイティブ) 現在の開発フォーマット。 pack-0.92 (とpack-0.92と互換性のある)フォーマットリポジトリにデータを変換できます。このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html をご覧下さるようお願いします。
development-subtree:
	(ネイティブ) 現在の開発フォーマット。サブツリーのバリアント。 pack-0.92-subtree (pack-0.92-subtreeと互換性のあるものなら何でも)フォーマットリポジトリから/へのデータの変換ができる。このフォーマットのリポジトリとブランチは bzr.devによってのみ読み込みできます。使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html をご覧下さるようお願いします。

廃止されたフォーマットは下記のとおりです。

metaweave:	(ネイティブ) 0.8の暫定的なフォーマット。knitよりも遅い
weave:	(ネイティブ) 0.8以前のフォーマット。knitよりも遅くチェックアウトと共用リポジトリをサポートしない。
knit:	(ネイティブ) knitを使用するフォーマット。0.14とそれ以前のbzrとの相互運用に推奨される。
dirstate:	(ネイティブ) 0.15での新しいフォーマット: ローカルオペレーションが速い。ネットワークを通してアクセスするときは0.8とそれ以降のbzrと互換性がある。
dirstate-tags:	(ネイティブ) 0.15での新しいフォーマット: 速いローカルオペレーションとネットワークオペレーションに関する改善されたスケーリング。タグ用のサポートを追加。0.15以前のbzrとは互換性がない
rich-root:	(ネイティブ) 1.0での新しいフォーマット。ツリーrootの扱いを改善。1.0以前のbzrと互換性がない。

詳細なストレージフォーマットは bzr help formats を参照してください。

リビジョンの識別子¶

リビジョンの識別子はブランチの履歴の特定の状態を参照します。これはリビジョン番号、もしくは ‘:’ が後に続くキーワード、と他のパラメータになります。識別子の例として ‘3’ 、 ‘last:1’ 、 ‘before:yesterday’ と ‘submit:’ などがあります。

‘REV1’ と ‘REV2’ がリビジョンの識別子である場合、 ‘REV1..REV2’ はリビジョンの範囲を表示します。例: ‘3647..3649’ 、 ‘date:yesterday..-1’ と ‘branch:/path/to/branch1/..branch:/branch2’ (‘..’周辺にはクォートもしくはスペースが存在しません)。

範囲は異なるコマンドによって異なる解釈がなされます。 “log” コマンドに対して、範囲はログメッセージのシーケンスで、 “diff” コマンドに対しては、範囲は(変更のシーケンスではなく)リビジョン間の変更を表示します。加えて、 “log” はclosed rangeを考慮するのに対して”diff”と”merge”はopen-endedとみなす、すなわち、これらは1つのendを含みますが他方は含みません。例です: “bzr log -r 3647..3649”はリビジョン3647、3648と3649のメッセージを表示するのに対して、 “bzr diff -r 3647..3649”は3647と3648の間に行われた変更を含み、3649の変更は含みません。

リビジョン選択方法として使用されるキーワードは次のとおりです:

revno:	番号を使用するリビジョンを選択する。
revid:	リビジョンidを使用するリビジョンを選択する。
last:	最後からn番目のリビジョンを選択する。
before:	指定されたリビジョンの親を選択する。
tag:	タグ名によって識別されるリビジョンを選択する。
date:	日付スタンプを基本とするリビジョンを選択する。
ancestor:	2番目のブランチで共通の祖先を選択する。
branch:	指定ブランチの最終リビジョンを選択する。
submit:	投稿ブランチで共通の祖先を選択する。

加えて、プラグインは他のキーワードを提供できます。

それぞれのキーワードの詳細な説明は下記のとおりです。

revno:	ブランチの履歴内のリビジョンを指定するために整数を使用する。オプションとしてブランチを指定できます。接頭辞の ‘revno:’ はオプションです。負の数はブランチの最後から数えます(-1は最後のリビジョン、-2はその前のリビジョン)。負の数がブランチの履歴よりも大きい場合、最初のリビジョンが返されます。例: revno:1 -> このブランチの最初のリビジョンを返す revno:3:/path/to/branch -> '/path/to/branch' ブランチの3番目のリビジョンを返す revno:-1 -> ブランチの最後のリビジョン。 -2:http://other/branch -> リモートブランチの最後から2番目のリビジョン。 -1000000 -> 履歴がとても長くなければ、おそらくは最初のリビジョン。
revid:	特定のリビジョンidを提供します。ブランチの祖先のリビジョンidを指定するために使用できます。マージと、マージの追加を含む。例: revid:aaaa@bbbb-123456789 -> リビジョン 'aaaa@bbbb-123456789' を選択する
last:	最後からn番目のリビジョンを取得するには正の数を提供する。負の数の提供に関しては ‘revno:’ の仕様と同じです。例: last:1 -> 最後のバージョンを返す。 last:3 -> 最後の2つ前のリビジョンを返す。
before:	そのリビジョンの親を返すリビジョンスペックを提供する。主にブランチのリビジョンの履歴の中に存在しないリビジョンを検査する際に便利です。 nullリビジョン(before:0)の親をリクエストするのは間違いです。例: before:1913 -> revno 1913の親を返す (revno 1912) before:revid:aaaa@bbbb-1234567890 -> リビジョンaaaa@bbbb-1234567890の親を返す bzr diff -r before:1913..1913 -> リビジョン1913とその親(1912)の間の変更を見つける (リビジョン1913が導入する変更が行うこと)。これは bzr diff -c 1913と同等です
tag:	タグはブランチに保存され、’tag’コマンドによって作成される。
date:	日付にマッチする最初のリビジョンを選択するためのデータスタンプを提供する。日付は ‘yesterday’、’today’、’tomorrow’ もしくはYYYY-MM-DDの文字列です。与えられた日付(深夜もしくは指定された時間のどちらか)の後の最初のエントリにマッチする。昨日以降のすべての変更を表示する方法の1つは次のとおりです: bzr log -r date:yesterday.. 例: date:yesterday -> 昨日以降の最初のリビジョンを選択する date:2006-08-14,17:10:14 -> August 14th, 2006 at 5:10pmの後の最初のリビジョンを選択する。
ancestor:	共通の祖先を選択するためにブランチへのパスを提供する。共通の祖先は両方のブランチの中に存在する最後のリビジョンです。通常これはブランチポイントですが、マージされたリビジョンにもなり得ます。リモートブランチからマージしなかった変更を除外する一方で、これはブランチが導入したすべての変更を返すために ‘diff’ でよく使用されます。例: ancestor:/path/to/branch $ bzr diff -r ancestor:../../mainline/branch
branch:	最後のリビジョンを選択するためにブランチへのパスを提供する。例: branch:/path/to/branch
submit:	これに対する差分は、このブランチで行われたすべての変更を表示し、マージされる予定のもののよい予測子です。投稿ブランチはbundleとmergeコマンドによって使用されます。投稿ブランチが指定されなければ、親ブランチが代わりに使用されます。共通の祖先は両方のブランチ内に存在する最終リビジョンです。通常これはブランチポイントですが、マージされたリビジョンにもなり得ます。例: $ bzr diff -r submit:

標準オプション¶

標準オプションはすべてのコマンドで有効です。

`--help, -h`	ヘルプメッセージを表示する。
`--verbose, -v`	詳細な情報を表示する。
`--quiet, -q`	エラーと警告のみ表示する。

グローバルオプションとは異なり、標準オプションはエイリアスで利用可能です。

ステータスフラグ¶

簡潔な方法で作業ツリーへの変更を要約するためにステータスフラグが使用されます。これらは次の形式をとります:

xxx   <filename>

カラムの意味は次のとおりです。カラム 1 - バージョン管理/リネーム:

+ バージョン管理されているファイル
- バージョン管理されていないファイル
R リネームされたファイル
? 未知のファイル
C 衝突した内容を持つファイル
P マージを追加するためのエントリ(ファイルではない)

カラム 2 - コンテンツ:

N 作成されたファイル
D 削除されたファイル
K 変更されたファイルの種類
M 修正されたファイル

カラム 3 - 実行:

* 実行が少し変更された

URLの識別子¶

サポートされるURLの接頭辞:

aftp://             アクティブFTPを利用したアクセス
bzr://              Bazaarスマートサーバーを利用したファーストアクセス
bzr+ssh://          SSHを通したBazaarスマートサーバーを利用したファーストアクセス
file://             標準ファイルシステムを利用したアクセス(デフォルト)
ftp://              パッシブFTPを利用したアクセス
http://             ウェブにエクスポートされたブランチへのリードオンリーのアクセス。
https://            SSLを利用したウェブにエクスポートされたブランチへのリードオンリーのアクセス。
sftp://             SFTPを利用したアクセス(大抵のSSHサーバーはSFTPを提供する)。

コマンド ¶

add¶

目的:

指定したファイルもしくはディレクトリを追加する。

使い方:

bzr add [FILE…]

オプション:

`--dry-run`	何が行われるか表示するが、実際には行わない。
`-v, --verbose`	詳細な情報を表示する。
`--no-recurse`	ディレクトリの内容を再帰的に追加しない。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`--file-ids-from=ARG`
	このツリーからファイルのidを探索する。

説明:

non-recursiveモードでは、以前無視されたファイルであっても、名前つきのすべてのアイテムが追加されます。名前つきファイルがすでにバージョン管理されている場合は警告が表示されます。

recursiveモード(デフォルト)では、ファイルは同じ方法で扱われますが、ディレクトリに対するふるまいは異なります。すでにバージョン管理されているディレクトリであれば警告は表示されません。すべてのディレクトリは、バージョン管理されているかいないかに関わらず、ファイルもしくはバージョン管理も無視もされているサブディレクトリのための検索対象になり、これらは追加されます。この検索はバージョン管理されたディレクトリにも再帰的に進められます。名前が渡されなければ、’.’が想定されます。

それゆえ単に ‘bzr add’ を実行すると現在未知であるファイルのすべてがバージョン管理されます。

親ディレクトリがバージョン管理されていないファイルを追加すると親およびそのrootまでも暗黙の内に追加されます。このことが意味するのはディレクトリを明示的に追加する必要はなく、ディレクトリの中のファイルを1つ追加するときにそれらのディレクトリも追加されます。

–dry-runは追加されるファイルを表示しますが、それらを実際に追加しません。

–file-ids-fromは提供されたパスからファイルのidの使用を試みます。これは同じファイル名を持ちマッチするディレクトリの発見をするためにidを探し、また純粋なパスによって行います。このオプションが必要になるのはめったにありませんが、後でマージする2つのブランチに同じ論理ファイルを追加するときに便利です(2つの異なる追加を衝突として表示しません)。別のプロジェクトをこのプロジェクトのサブディレクトリにマージする際にも便利です。

関連コマンド:

remove

alias¶

目的:

エイリアスの設定/設定解除と表示を行う。

使い方:

bzr alias [NAME]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`--remove`	エイリアスを削除する。
`-h, --help`	ヘルプメッセージを表示する。

例:

現在のエイリアスを表示するには:

bzr alias

‘ll’用に指定されたエイリアスを表示するには:

bzr alias ll

‘ll’のエイリアスを設定するには:

bzr alias ll="log --line -r-10..-1"

‘ll’のエイリアスを削除するには:

bzr alias --remove ll

annotate¶

目的:

ファイルのそれぞれの行のoriginを表示する。

使い方:

bzr annotate FILENAME

オプション:

`--all`	すべての行の注釈を表示する。
`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--long`	注釈のコミット日時を表示する。
`--show-ids`	内部のオブジェクトidを表示する。
`-r ARG, --revision=ARG`
	“help revisionspec”の詳細を参照。

説明:

このコマンドは与えられたファイルの、変更によって導入されたリビジョン、筆者と日付を示す注釈を左側で表示します。

連続した行の続きに関してoriginが同じ場合、 –allオプションが渡されない限り、これはトップでのみ表示されます。

エイリアス:

ann, blame, praise

bind¶

目的:

現在のブランチを提供されたブランチのチェックアウトに変換する。

使い方:

bzr bind [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

チェックアウトに変換されると、コミットはローカルブランチに適用される前にコミットはマスターブランチを継承しなければなりません。

ローカルに設定されない限りバインドされたブランチはマスターブランチのニックネームを使用します。この場合、バインディングはローカルなニックネームをマスターのものに更新します。

関連コマンド:

checkout, unbind

branch¶

目的:

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

使い方:

bzr branch FROM_LOCATION [TO_LOCATION]

オプション:

`--stacked`	ソースブランチを参照するスタックドブランチを作成する。すべてのオペレーションに関して新しいブランチはソースブランチの利用可能性に依存する。
`-v, --verbose`	詳細な情報を表示する。
`--standalone`	利用可能であっても共用リポジトリを使用しない。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--hardlink`	可能な作業ツリーファイルをハードリンクする。
`-r ARG, --revision=ARG`
	詳細は “help revisionspec” を参照。

説明:

TO_LOCATIONが省略されると、FROM_LOCATIONの最終コンポーネントが使用されます。言い換えると、 “branch ../foo/bar” は./bar を作成しようとします。 FROM_LOCATIONが/を持たないもしくは埋め込みのパスの区切り文字を持つ場合冒頭のスキームもしくはドライブの識別子を剥ぎ取ることで、 FROM_LOCATIONからTO_LOCATIONが得られます。たとえば、”branch lp:foo-bar”は./foo-barを作成しようとします。

ブランチの特定のリビジョンを読み取るには、 “branch foo/bar -r 5”のような、–revisionパラメータを提供します。

エイリアス:

get, clone

関連コマンド:

checkout

break-lock¶

目的:

リポジトリ、ブランチもしくは作業ディレクトリのデッドロックをブレークする。

使い方:

bzr break-lock [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

警告: ロックを保持するプロセスが停止したときにのみロックはブレークします。

‘bzr info’コマンドを通して開いているロックに関する情報を得ることができます。

例:

bzr break-lock

cat¶

目的:

与えられたリビジョンのファイルの内容を標準出力に書き込む。

使い方:

bzr cat FILENAME

オプション:

`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--name-from-revision`
	古いツリーのパス名。
`-h, --help`	ヘルプメッセージを表示する。

説明:

リビジョンが指定されなければ、最後のリビジョンが使用されます。

注意: バイナリファイルでこのコマンドを使用する際には: 標準出力をリダイレクトするように気をつけてください。

関連コマンド:

ls

check¶

目的:

作業ツリーの構造、ブランチの一貫性、とリポジトリの履歴をバリデートする。

使い方:

bzr check [PATH]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--tree`	現在のディレクトリに関連した作業ツリーをチェックする。
`-q, --quiet`	エラーと警告だけ表示する。
`--repo`	現在のディレクトリに関連したリポジトリをチェックする。
`--branch`	現在のディレクトリに関連したブランチをチェックする。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドはデータの破損もしくはbzrのバグを検出するためにブランチとリポジトリストレージに関するさまざまな不変量をチェックします・

問題が検出された場合のみ作業ツリーとブランチのチェックは出力をします。リポジトリチェックの出力フィールドは次のとおりです:

revisions: これはチェックされるリビジョンの番号です。

これは問題を示しません。

versionedfiles: これはチェックされるバージョン管理されたファイルの数です。

これは問題を示しません。

unreferenced ancestors: 他のテキストの祖先であるテキストは、

リビジョンの祖先によって適切に参照されません。これはBazaarが対処できるsubtleな問題です。

unique file texts: チェックされるリビジョンで見つかる

ファイルの内容の合計数です。これは問題を示しません。

repeated file texts: チェックされるリビジョンで見つかる、

繰り返されるテキストの合計数です。テキストのエントリが修正されたときにテキストは繰り返しできますが、ファイルの内容は繰り返しできません。これは問題を示しません。

制限が指定されなければ、すべてのBazaarデータはチェックされる位置で見つかります。

例:

‘foo’ でのツリーとブランチをチェックする:

bzr check --tree --branch foo

‘bar’でのリポジトリのみをチェックする:

bzr check --repo bar

‘baz’ ですべてをチェックする:

bzr check baz

関連コマンド:

reconcile

checkout¶

目的:

既存のブランチの新しいチェックアウトを作成する。

使い方:

bzr checkout [BRANCH_LOCATION] [TO_LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`--files-from=ARG`
	このツリーからファイルの内容を取得する。
`-q, --quiet`	エラーと警告のみを表示する。
`--hardlink`	利用可能な作業ツリーファイルをハードリンクする。
`--lightweight`	軽量チェックアウトを実行する。オペレーションに関して軽量チェックアウトはブランチへの権限に依存する。通常のチェックアウトはdiffやstatusのようなアクセスが不要な共通のオペレーションを実行可能で、ローカルコミットもサポートします。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

BRANCH_LOCATIONが省略されると、’.’で見つかるブランチ用にチェックアウトは作業ツリーを再構成します。作業ツリーを削除した場合もしくはこれがけっして作成されない場合 - すなわち、SFTPを使用してブランチを現在の位置にpushする場合、これは便利です。

TO_LOCATIONが省略されると、BRANCH_LOCATIONの最後のコンポーネントが使用されます。言い換えると、”checkout ../foo/bar” は./barを作成しようとします。 BRANCH_LOCATIONが has no /を持たないもしくはパスの区切り文字が埋め込まれている場合、先頭のスキームもしくはドライブの識別子を除去することでBRANCH_LOCATIONからTO_LOCATIONが得られます。たとえば、”checkout lp:foo-bar”は./foo-barを作成しようとします。

特定のリビジョンのブランチを読み取るには、 “checkout foo/bar -r 5”のように–revisionパラメータを提供します。これはすぐに時代遅れになりますが[なのでコミットできない] 役に立つことがあります(すなわち古いコードを検査するため)。

エイリアス:

co

関連コマンド:

branch, チェックアウト

commit¶

目的:

変更を新しいリビジョンにコミットする。

使い方:

bzr commit [SELECTED…]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--author=ARG`	著者の名前がコミッターとは異なる場合、著者の名前を設定する。
`--unchanged`	何も変更されていなくてもコミットする。
`--fixes=ARG`	このリビジョンをバグが修正されたものとしてマークする。
`-q, --quiet`	エラーと警告のみを表示する。
`--show-diff`	メッセージが提供されないとき、メッセージエディタでステータスの要約と一緒に差分を表示する。
`--strict`	作業ツリーの中に未知のファイルが存在する場合コミットを拒否する。
`-F MSGFILE, --file=MSGFILE`
	このファイルからコミットメッセージを取得する。
`-x ARG, --exclude=ARG`
	与えられたパスへの変更を考慮しない。
`-m ARG, --message=ARG`
	新しいリビジョンの説明。
`--local`	バインドされたブランチにローカルコミットを実行する。通常のコミットが実行されるまでローカルコミットはマスターブランチにpushされません。
`-h, --help`	ヘルプメッセージを表示する。

説明:

引数が渡されなければ、ツリー全体がコミットされます。

選択されたファイルが指定されると、これらのファイルへの変更のみがコミットされます。ディレクトリが指定されるとディレクトリとその中のすべてがコミットされます。

excludesが渡されるとき、これらは選択されたファイルよりも優先されます。たとえば、fooの範囲での変更のみコミットされますが、foo/barの範囲の変更はコミットされません:

bzr commit foo -x foo/bar

変更の著者がコミッターと同じ人物でなければ、 –authorオプションを使用して著者の名前を指定できます。名前はコミッターidと同じフォーマットです。たとえば”John Doe <jdoe@example.com>”です。

コミットされるツリーが無効である場合選択されたファイルのコミットが失敗することがあります。次の一連のコマンドを考えてみましょう:

bzr init foo
mkdir foo/bar
bzr add foo/bar
bzr commit foo -m "committing foo"
bzr mv foo/bar foo/baz
mkdir foo/bar
bzr add foo/bar
bzr commit foo/bar -m "committing bar but not baz"

上記の例において、最終コミットは故意に失敗します。これによってユーザーは、同時に、最初に個別に、もしくはまったくリネームしたくないかどうかを決める機会を得ます。 (一般的なルールとして、判断がつかないとき、Bazaarは安全に物事を行う方針を持ちます。)

注: マージの後の選択されたファイルのコミットはまだサポートされていません。

エイリアス:

ci, checkin

関連コマンド:

bugs, uncommit

conflicts¶

目的:

衝突を持つファイルの一覧を表示する。

使い方:

bzr conflicts

オプション:

`--text`	テキストの衝突を持つファイルのパスの一覧を表示する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

マージは2つのブランチの変更を結合するために最善を尽くしますが、人間だけが修正できるある種の問題が存在します。この問題に遭遇するとき、衝突がマークされます。衝突はコミットする前に何かを修正する必要があることを意味します。

通常の衝突は短く人間が読めるメッセージとして一覧が示されます。 –textが提供される場合、代わりに、テキストの衝突を持つファイルのパスの一覧が表示されます。 (これはテキストの衝突を持つファイルをすべて編集するために便利です。)

問題を修正したらbzr resolveを使用します。

関連コマンド:

resolve

deleted¶

目的:

作業ツリーの中で削除されたファイルの一覧を表示する。

使い方:

bzr deleted

オプション:

`--show-ids`	内部のオブジェクトidを表示する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

関連コマンド:

ls, status

diff¶

目的:

リビジョンもしくはブランチの間の、作業ツリーの中の違いを表示する。

使い方:

bzr diff [FILE…]

オプション:

`--old=ARG`	から比較するブランチ/ツリー。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-p ARG, --prefix=ARG`
	コロンによって区切られた2つの値として新旧のファイル名に追加される接頭辞を設定する(たとえば”old/:new/”)。
`--using=ARG`	ファイルを比較するためにこのコマンドを使用する。
`--new=ARG`	へ比較するブランチ/ツリー。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`--diff-options=ARG`
	これらのオプションを外部diffプログラムに渡す。
`-c ARG, --change=ARG`
	指定されたリビジョンによって導入された変更を選択する。 “help revisionspec”も参照。
`-h, --help`	ヘルプメッセージを表示する。

説明:

引数が渡されなければ、現在のツリーに対するすべての変更の一覧が表示されます。ファイルが渡されれば、これらのファイルの中の変更の一覧だけが表示されます。リモートと複数のブランチは–oldと–newオプションを使用して比較できます。これらのオプションが提供されなければ、両方のデフォルトは、存在すれば最初の引数、引数が渡されなければ現在のツリーから得られます。

“bzr diff -p1” は “bzr diff –prefix old/:new/”と同等で、 “patch -p1”に最適なパッチが生成されます。

例:

作業ツリーと最終コミットの間の違いを表示する:

bzr diff

作業ツリーとリビジョン1の間の違い:

bzr diff -r1

リビジョン1とリビジョン2の間の違い:

bzr diff -r1..2

ブランチxxxのリビジョン1とリビジョン2の間の違い:

bzr diff -r1..2 xxx

NEWSファイルの違いだけ表示する:

bzr diff NEWS

NEWSファイルに対する作業ツリーの中の違いを表示する:

bzr diff xxx/NEWS

xxxブランチからこの作業ツリーの違いを表示する:

bzr diff –old xxx

NEWSファイルに対する2つのブランチの違いを表示する:

bzr diff --old xxx --new yyy NEWS

‘bzr diff’と同じであるがold/とnew/でパスに接頭辞を追加する:

bzr diff --prefix old/:new/

Exitの値:

1 - 変更された 2 - 表現できない変更 3 - エラー 0 - 変更なし

エイリアス:

di, dif

関連コマンド:

status

export¶

目的:

現在のリビジョンを指定されたディレクトリもしくはアーカイブにエクスポートする。

使い方:

bzr export DEST [BRANCH_OR_SUBDIR]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--format=ARG`	Type of file to export to.
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--root=ARG`	エクスポートされたファイル内部のrootディレクトリの名前。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

リビジョンが指定されなければこれは最終コミットのリビジョンをエクスポートします。

フォーマットはtar、tgz、tbz2のような”exporter”の名前になることができます。何も渡されなければ、拡張子かｒフォーマットを見つけようとします。拡張子が見つからなければディレクトリにエクスポートします(–format=dirと同等)。

rootが提供されると、これはコンテナフォーマット(tar、zip、その他)内部のrootディレクトリとして使用されます。これが提供されなければエクスポートされるファイル名へのデフォルトになります。 rootオプションは’dir’フォーマットに対して効果がありません。

ブランチが省略されると現在の作業ディレクトリを含むブランチが使用されます。

注: ASCIIではないファイル名でのツリーのエクスポートはサポートされません。

サポートされるフォーマット拡張子で自動検出

dir (none)

tar .tar

tbz2 .tar.bz2, .tbz2

tgz .tar.gz, .tgz

zip .zip

help¶

目的:

コマンドもしくは他のトピックのヘルプを表示する。

使い方:

bzr help [TOPIC]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`--long`	すべてのコマンドのヘルプを表示する。
`-h, --help`	ヘルプメッセージを表示する。

エイリアス:

?, –help, -?, -h

関連コマンド:

topics

ignore¶

目的:

指定されたファイルもしくはパターンを無視する。

使い方:

bzr ignore [NAME_PATTERN…]

オプション:

`--old-default-rules`
	bzr < 0.9で使用される無視ルールを書き出す。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

パターンの構文の詳細は bzr help patterns を参照。

無視リストからパターンを除外するには、.bzrignoreファイルを編集します。追加した後で、コマンドを使用して間接的に、もしくはエディタを使用して直接そのファイルを編集もしくは削除した後で、そのコミットを確認してください。

注: シェルのワイルドカードを含む無視パターンはUnixのシェルからクォートされなければなりません。

例:

トップレベルのMakefileを無視する:

bzr ignore ./Makefile

すべてのディレクトリのクラスファイルを無視する:

bzr ignore "*.class"

libディレクトリ下の.oファイルを無視する:

bzr ignore "lib/**/*.o"

libディレクトリ下の.oファイルを無視する:

bzr ignore "RE:lib/.*\.o"

“debian”トップレベルディレクトリ以外のすべてを無視する:

bzr ignore "RE:(?!debian/).*"

関連コマンド:

ignored, パターン, status

ignored¶

目的:

無視するファイルとそれらにマッチするパターンの一覧を表示する。

使い方:

bzr ignored

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

無視されるファイルと無視パターンのすべての一覧を表示します。

代わりにファイルの一覧だけを表示するには:

bzr ls --ignored

関連コマンド:

ignore, ls

info¶

目的:

作業ツリー、ブランチもしくはリポジトリに関する情報を表示する。

使い方:

bzr info [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドはツリー、ブランチもしくはリポジトリに関連する既知の位置とフォーマットのすべてを表示します。統計情報はそれぞれのレポートに含まれます。

ブランチと作業ツリーは見つからないリビジョンもレポートします。

関連項目:

リポジトリ, revno, 作業ツリー

init¶

目的:

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

使い方:

bzr init [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--create-prefix`
	ブランチに通じるパスがまだ存在していなければそれを作成する。
`--append-revisions-only`
	revnosもしくは既存のログを変更しない。リビジョンを追加するのみ。
`-q, --quiet`	エラーと警告のみを表示する。
`-h, --help`	ヘルプメッセージを表示する。

ブランチのフォーマット:

--format=ARG        このブランチのフォーマットを指定する。"help formats"を参照。
--1.12-preview      ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
--1.12-preview-rich-root
                    rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
--1.6               スタックをサポートするリポジトリに基づいたブランチとパック。
--1.6.1-rich-root   スタックとリッチなrootデータをサポートするリポジトリに基づいた
                    ブランチとパック(bzr-svnに必要)。
--1.9               btreeインデックスを使用するリポジトリに基づいたブランチとパック
--1.9-rich-root     btreeインデックスとリッチrootデータを使用する
                    リポジトリに基づいたブランチとパック(bzr-svnに必要)。
--default           0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用しますが
                    bzr < 0.92では読むことができません。
                    以前はknitpack-experimentalと呼ばれていました。
                    詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
--development       現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
--development-subtree
                    現在の開発フォーマットで、subtreeバリアント。
                    データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
                    repo.html をご覧いただくようお願いします。
--dirstate          0.15の新しいフォーマット: 速いローカルオペレーション。
                    ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
--dirstate-tags     0.15の新しいフォーマット: 速いローカルオペレーションで
                    ネットワークオペレーションに関するスケーリングを改善。
                    タグのサポートを追加。bzr < 0.15とは互換性がない。
--knit              knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
--metaweave         0.8での暫定フォーマット。knitよりも遅い。
--pack-0.92         0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
                    以前はknitpack-experimentalと呼ばれていた。
                    詳細な情報に関しては、 http://doc
                    .bazaar-vcs.org/latest/developers/packrepo.html を参照。
--rich-root         1.0の新しいフォーマット。ツリーrootのベターな扱い。
                    bzr < 1.0と互換性がない。
--rich-root-pack    1.0の新しいフォーマット: rich-rootデータをサポートする
                    pack-0.92のバリアント(bzr-svnに必要)。
--weave             0.8以前のフォーマット。knitよりも遅く
                    チェックアウトもしくは共用リポジトリをサポートしない。

説明:

空のブランチを作成するもしくは既存のプロジェクトをインポートする前に使用します。

親ディレクトリの位置にリポジトリが存在する場合、ブランチの履歴はリポジトリに保存されます。さもなければinitは.bzrのディレクトリに独自の履歴を運ぶスタンドアロンのブランチを作成します。

ロケーションにブランチがすでにあるが作業ツリーがない場合、ツリーは’bzr checkout’で投入できます。

ファイルのツリーをインポートする方法のレシピです:

cd ~/project
bzr init
bzr add .
bzr status
bzr commit -m "imported project"

関連コマンド:

branch, checkout, init-repository

init-repository¶

目的:

ブランチを保持する共用リポジトリを作成する。

使い方:

bzr init-repository LOCATION

オプション:

`--no-trees`	リポジトリのブランチはデフォルトで作業ツリーを持ちません。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-h, --help`	ヘルプメッセージを表示する。

ブランチのフォーマット:

--format=ARG        このブランチのフォーマットを指定する。"help formats"を参照。
--1.12-preview      ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
--1.12-preview-rich-root
                    rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
--1.6               スタックをサポートするリポジトリに基づいたブランチとパック。
--1.6.1-rich-root   スタックとリッチなrootデータをサポートするリポジトリに基づいた
                    ブランチとパック(bzr-svnに必要)。
--1.9               btreeインデックスを使用するリポジトリに基づいたブランチとパック
--1.9-rich-root     btreeインデックスとリッチrootデータを使用する
                    リポジトリに基づいたブランチとパック(bzr-svnに必要)。
--default           0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用しますが
                    bzr < 0.92では読むことができません。
                    以前はknitpack-experimentalと呼ばれていました。
                    詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
--development       現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
--development-subtree
                    現在の開発フォーマットで、subtreeバリアント。
                    データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
                    repo.html をご覧いただくようお願いします。
--dirstate          0.15の新しいフォーマット: 速いローカルオペレーション。
                    ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
--dirstate-tags     0.15の新しいフォーマット: 速いローカルオペレーションで
                    ネットワークオペレーションに関するスケーリングを改善。
                    タグのサポートを追加。bzr < 0.15とは互換性がない。
--knit              knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
--metaweave         0.8での暫定フォーマット。knitよりも遅い。
--pack-0.92         0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
                    以前はknitpack-experimentalと呼ばれていた。
                    詳細な情報に関しては、 http://doc
                    .bazaar-vcs.org/latest/developers/packrepo.html を参照。
--rich-root         1.0の新しいフォーマット。ツリーrootのベターな扱い。
                    bzr < 1.0と互換性がない。
--rich-root-pack    1.0の新しいフォーマット: rich-rootデータをサポートする
                    pack-0.92のバリアント(bzr-svnに必要)。
--weave             0.8以前のフォーマット。knitよりも遅く
                    チェックアウトもしくは共用リポジトリをサポートしない。

説明:

ブランチのディレクトリではなく、リポジトリにリビジョンを保存するリポジトリディレクトリの元で作成された新しいブランチ。

–no-treesオプションが使用されるとリポジトリのブランチはデフォルトで作業ツリーを持ちません。

例:

ブランチだけを保有する共用リポジトリを作成する:

bzr init-repo --no-trees repo
bzr init repo/trunk

軽量チェックアウトを作成する:

bzr checkout --lightweight repo/trunk trunk-checkout
cd trunk-checkout
(add files here)

エイリアス:

init-repo

関連項目:

branch, checkout, init, リポジトリ

log¶

目的:

ブランチ、ファイル、もしくはディレクトリのログを表示する。

使い方:

bzr log [LOCATION]

オプション:

`-v, --verbose`	それぞれのリビジョンで変更されたファイルを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-l N, --limit=N`
	出力を最初のNのリビジョンに制限する。
`--forward`	最古から最新までを表示する。
`--timezone=ARG`	ローカル、オリジナル、utcのタイムゾーンを表示する。
`--show-ids`	内部オブジェクトidを表示する。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`-m ARG, --message=ARG`
	メッセージが正規表現にマッチするリビジョンを表示する。
`-c ARG, --change=ARG`
	指定されたリビジョンだけを表示する。”help revisionspec”も参照。
`-h, --help`	ヘルプメッセージを表示する。

ログのフォーマット::

`--log-format=ARG`
	指定されたログフォーマットを使用する。
`--line`	リビジョン単位の1行のログフォーマット
`--long`	詳細なログフォーマット
`--short`	適切に短いログフォーマット

説明:

デフォルトでは作業ディレクトリを含むブランチのログを表示する。

ログの範囲をリクエストするには、-r begin..endコマンドを使用できます。 -r revisionは指定したリビジョンをリクエストし、 -r ..end もしくは -r begin.. も有効です。

例:

現在のブランチのログ:

bzr log

ファイルのログ:

bzr log foo.c

ブランチの最後の10リビジョンのログ:

bzr log -r -10.. http://server/branch

ls¶

目的:

ツリーのファイルの一覧を表示する。

使い方:

bzr ls [PATH]

オプション:

`--from-root`	ブランチのrootから相対的なパスを出力する。
`--ignored`	無視されたファイルを出力する。
`--kind=ARG`	特定の種類:file、directory、symlinkのエントリの一覧を表示する。
`-v, --verbose`	詳細な情報を表示する。
`-V, --versioned`
	バージョン管理されたファイルを出力する。
`--unknown`	未知のファイルを出力する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--non-recursive`
	サブディレクトリで再帰的処理を行わない。
`--show-ids`	内部オブジェクトidを表示する。
`--null`	ファイルの間に改行の代わりに NUL (0) 区切り文字を書く。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

関連項目:

cat, status

merge¶

目的:

三方向マージを実行する。

使い方:

bzr merge [LOCATION]

オプション:

`--pull`	すでに対象が完全にソースにマージされる場合、マージよりもソースからpullする。これが起きるとき、結果をコミットする必要はない。
`--remember`	指定されたロケーションをデフォルトとして記録する。
`--force`	目的のツリーがコミットされていない変更を持っていてもマージする。
`-v, --verbose`	詳細な情報を表示する。
`--reprocess`	誤った衝突を減らすために再処理する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--uncommitted`	ブランチの変更の代わりに、作業ツリーからコミットされていない変更を適用する。
`-d ARG, --directory=ARG`
	作業ディレクトリを含むものよりも、マージするブランチ。
`--show-base`	衝突のベースリビジョンテキストを表示する。
`--preview`	マージする代わりに、マージの差分を表示する。
`-c ARG, --change=ARG`
	指定されたリビジョンで導入された変更を選択する。 “help revisionspec”も参照。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

マージアルゴリズム::

`--merge-type=ARG`
	特定のマージアルゴリズムを選択する。
`--diff3`	外部diff3を使用するマージ
`--lca`	新しいLCAマージ
`--merge3`	ネイティブのdiff3スタイルのマージ
`--weave`	weaveベースのマージ

説明:

マージのソースはブランチの形式、もしくはbzr sendで生成された mergeディレクティブを含むファイルへのパスの形式で指定できます。どちらも指定されなければ、デフォルトは上流ブランチもしくは –rememberを使用して最近マージされたブランチです。

マージをブランチするとき、デフォルトではチップがマージされます。異なるリビジョンをピックするには、–revisionを渡します。 2つの値を指定する場合、最初の値はBASEとして、2番目の値はOTHERとして使用されます。個別のリビジョン、もしくはこのように利用可能なリビジョンのサブセットをマージすることは一般的に”チェリーピック”として言及されます。

リビジョン番号はマージされるブランチに対して常に相対的です。

デフォルトでは、bzrは、自動的に適切なベースを検出して、他のブランチからすべてのネットワークでマージしようとします。これが失敗すると、明示的なベースを渡すことが必要になることがあります。

マージは2つのブランチの変更を結合するために最善を尽くしますが、人間だけが修正できる種類の問題があります。この問題に遭遇するとき、衝突マークがつけられます。衝突はコミットする前に何かを修正する必要があることを意味します。

問題を修正したらbzr resolveを使用します。bzr conflictsも参照してください。

デフォルトのブランチセットが存在しない場合、最初のマージはそれを設定します。その後で、デフォルトを使用するブランチを省略できます。デフォルトを変更するには、–rememberを使用します。リモートロケーションがアクセス可能場合のみ値は保存されます。

マージの結果は目的の作業ディレクトリに設置されます。このディレクトリは(bzr diffで)閲覧、テスト、とマージの結果を記録するためにコミット可能です。

–forceが渡されない限り、コミットされていない変更が存在すればマージの実行は拒否されます。

例:

bzr.devから最新のリビジョンをマージするには:

bzr merge ../bzr.dev

bzr.devからリビジョン82を含めて変更をマージするには:

bzr merge -r 82 ../bzr.dev

以前の変更なしに、82で導入された変更をマージするには:

bzr merge -r 81..82 ../bzr.dev

/tmp/mergeに含まれるmergeディレクトリを適用するには:

bzr merge /tmp/merge

関連項目:

remerge, status-flags, update

missing¶

目的:

2つのブランチの間のmergeされていない/pullされていないリビジョンを表示する。

使い方:

bzr missing [OTHER_BRANCH]

オプション:

`--reverse`	リビジョンの順序をリバースする。
`--this`	–mine-onlyと同じ。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`--other`	–theirs-onlyと同じ。
`--include-merges`
	マージされたリビジョンを表示する。
`--mine-only`	ローカルブランチの変更のみを表示する。
`--show-ids`	内部オブジェクトidを表示する。
`--theirs-only`	リモートブランチの変更のみを表示する。
`-v, --verbose`	詳細な情報を表示する。

ログフォーマット::

`--log-format=ARG`
	指定したログフォーマットを使用する。
`--line`	リビジョンごとの1行のログフォーマット
`--long`	詳細なログフォーマット
`--short`	適切に短いログフォーマット

説明:

OTHER_BRANCHはlocalもしくはremoteになります。

関連項目:

merge, pull

mkdir¶

目的:

バージョン管理下にある新しいディレクトリを作成する。

使い方:

bzr mkdir DIR…

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

これはディレクトリの作成と追加と同等です。

mv¶

目的:

ファイルを移動もしくはリネームする。

使い方:

bzr mv OLDNAME NEWNAME

bzr mv SOURCE… DESTINATION

オプション:

`--after`	ファイルがすでに移動しているので、ファイルのbzr識別子のみを移動させる。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

最後の引数がバージョン管理されているディレクトリの場合、他のすべての名前はそこに移動します。さもなければ、2つの引数だけにしなければならずファイルは新しい名前に変更されます。

OLDNAMEがファイルシステム上に存在しないがバージョン管理されていて NEWNAMEはファイルシステム上に存在せずバージョン管理もされていない場合、 mvはファイルが手動で移動させられその変更を反映するために内部インベントリだけを更新することを想定します。多くのSOURCEファイルをDESTINATIONに移動させるときも同じです。

ブランチの間でファイルを移動させることはできません。

エイリアス:

move, rename

nick¶

目的:

ブランチのニックネームを表示もしくは設定する。

使い方:

bzr nick [NICKNAME]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

設定が解除されると、ツリーのrootディレクトリの名前がニックネームとして使用されます。現在のニックネームを表示するには、引数なしで実行します。

ローカルに設定されていない限りバインドされたブランチはマスターブランチのニックネームを使用します。

関連コマンド:

info

pack¶

目的:

リポジトリ内のデータを圧縮する。

使い方:

bzr pack [BRANCH_OR_REPO]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

関連コマンド:

リポジトリ

plugins¶

目的:

インストールされたプラグインの一覧を表示する。

使い方:

bzr plugins

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドはプラグインのバージョンとそれぞれの手短な説明を含めてインストールされたプラグインの一覧を表示します

–verboseはそれぞれのプラグインが設置されたパスを表示します。

プラグインはコードを追加したり置き換えたりすることでリビジョン管理システムを拡張する外部コンポーネントです。コマンドの上書き、新しいコマンドの追加、追加のネットワーク転送の提供やログ出力のカスタマイズなどを含めてプラグインはさまざまなことを行うことができます。

プラグインを見つけてインストール方法を含めた詳細な情報に関しては、 Bazaarのウェブサイト、http://bazaar-vcs.org を参照してください。プログラミング言語のPyhonを利用して新しいコマンドを作成する方法に関する手引きもあります。

pull¶

目的:

このブランチを別のブランチのミラーにする。

使い方:

bzr pull [LOCATION]

オプション:

`-v, --verbose`	pullされたリビジョン用のログを表示する。
`--remember`	デフォルトとして指定されたロケーションを記録する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-d ARG, --directory=ARG`
	作業ディレクトリを含むものよりもpullするブランチ。
`--overwrite`	ブランチの間の違いを無視して無条件で上書きする。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

このコマンドは分岐されていないブランチのみで動作します。目的のブランチの最新の変更コミットが親にマージされなかった場合(直接もしくは間接)、ブランチは分岐したものとして見なされます。

ブランチが分岐していれば、あるブランチからの変更を他のブランチに統合するために ‘bzr merge’を使用できます。一旦あるブランチがマージされると、他のブランチは再びそれをpullできるようになります。

ローカルの変更を忘れてリモートブランチを満たすようにブランチを更新したいだけなら、 pull –overwriteを使用します。

デフォルトのロケーションが存在しない場合、最初のpullはこれを設定します。その後で、デフォルトを使用するロケーションを省略できます。デフォルトを変更するには、–rememberを使用します。リモートロケーションがアクセスできる場合のみ値は保存されます。

注: 位置がブランチのフォーマットもしくはbzr sendで生成されたmergeディレクトリを格納する: ファイルへのパスで指定できます。

関連項目:

push, status-flags, update

push¶

目的:

このブランチのミラーを更新する。

使い方:

bzr push [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--remember`	指定された位置をデフォルトとして覚える。
`--create-prefix`
	まだ存在しなればブランチへのパスを作成する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--stacked-on=ARG`
	コミットの履歴に関して別のブランチを参照するスタックドブランチを作成する。参照されるブランチに存在しない作業内容は作成されたブランチに格納される。
`--use-existing-dir`
	デフォルトでは、ターゲットのディレクトリが存在するがまだコントロールディレクトリを持たない場合pushは失敗する。このフラグはpushの続行を可能にする。
`-d ARG, --directory=ARG`
	作業ディレクトリを含むブランチよりも、pushするブランチ
`--stacked`	親ブランチの公開位置を参照するスタックドブランチを作成する。
`--overwrite`	ブランチ間の違いを無視して無条件に上書きする。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

これは割高でリモートファイルシステムではサポートされないので、ターゲットブランチは投入された作業ツリーを持ちません。

スマートサーバーもしくはプロトコルの中には将来作業ツリーを導入しないものがあります。

このコマンドは分岐されていないブランチでのみ動作します。目的のブランチの最新のコミットがソースブランチによって(直接もしくは間接的に)マージされなければブランチは分岐されたものとして見なされます。

ブランチが分岐されると、他のブランチを完全に置き換えるために ‘bzr push –overwrite’を使用できます。この場合、マージされていない変更は廃棄されます。

他のブランチに異なる変更があることを保証したい場合は、他のブランチからマージを行い(bzr help mergeを参照)、それをコミットします。その後で’–overwrite’なしでpushを行うことができるようになります。

デフォルトのpush位置の設定がなければ、最初のpushはこれを設定します。その後では、デフォルトを省略できます。デフォルトを変更するには、–rememberを使用します。リモート位置がアクセスできる場合のみ値は保存されます。

関連項目:

pull, update, working-trees

reconcile¶

目的:

ブランチのメタデータを調整する。

使い方:

bzr reconcile [BRANCH]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

これは以前の実在しないオペレーションもしくはbzrの更新によって引き起こされるデータのミスマッチを訂正できます。 ‘bzr check’もしくはbzrの開発者がそのコマンドを実行するようにアドバイスするのであれば、このコマンドを実行することだけが必要になります。

2番目のブランチが提供されると、ブランチをまたがる調整も行われます。これによってbzrの初期のバージョンでは存在しなかったツリーのroot idのようなデータがチェックされ、両方のブランチで正しく表示されます。

同時にデータが再圧縮されるのでディスクスペースの節約やパフォーマンスのゲインにつながります。

ブランチはローカルディスクもしくはsftpのようにリスト可能なシステム上になければなりません。

関連項目:

check

reconfigure¶

目的:

bzrディレクトリのタイプを再設定する。

使い方:

bzr reconfigure [LOCATION]

オプション:

`--force`	ローカルの変更が失われていた場合でも再設定を実行する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--bind-to=ARG`	チェックアウトをバインドするブランチ。
`-h, --help`	ヘルプメッセージを表示する。

Target type:

`--branch`	作業ツリーを持たないバインドされていないブランチに再設定する。
`--checkout`	作業ツリーを持つバインドされたブランチに再設定する。
`--lightweight-checkout`
	軽量チェックアウトに再設定する(ローカルの履歴はなし)。
`--standalone`	スタンドアロンブランチに再設定する(すなわち共用リポジトリの使用を停止する)。
`--tree`	作業ツリーを持つバインドされていないブランチに再設定する。
`--use-shared`	共用リポジトリを使用するように再設定する。

説明:

ターゲットの設定を指定しなければなりません。

チェックアウトに関しては指定されていなければ、bind-toのロケーションは自動検出されます。優先順位は 1. 軽量チェックアウトに関しては、現在バインドされているロケーション。 2. チェックアウトに使用されるブランチに関しては、以前バインドされたロケーション。 3. pushのロケーション。 4. 親のロケーション。これらが利用できなければ、–bind-toを指定しなければなりません。

関連項目:

ブランチ, チェックアウト, スタンドアロンのツリー, 作業ツリー

remerge¶

目的:

マージを再び行う。

使い方:

bzr remerge [FILE…]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`--reprocess`	誤った衝突を減らすために再処理する。
`-q, --quiet`	エラーと警告のみ表示する。
`--show-base`	衝突内のベースリビジョンのテキストを表示する。
`-h, --help`	ヘルプメッセージを表示する。

マージアルゴリズム:

`--merge-type=ARG`
	特定のマージアルゴリズムを指定する。
`--diff3`	外部diff3を使用するマージ
`--lca`	新しいLCAマージ
`--merge3`	ネイティブのdiff3スタイルのマージ
`--weave`	weaveベースのマージ

説明:

衝突を解消している間に異なるマージテクニックを試したい場合はこれを使用します。マージテクニックの中には他のものよりもすぐれたものがあり、 remergeによって異なるファイルで異なるテクニックを試すことができます。 remergeのオプションはmergeのものと同じ意味とデフォルトを持ちます。違いは未解決のマージが存在するときのみremergeは実行できて特定のファイルを指定できることです。

例:

すべてのファイルのマージを再実行し、通常のTHISとOTHERテキストに加えて、衝突領域のベーステキストを表示する:

bzr remerge --show-base

weaveマージアルゴリズムを使用して”foobar”のマージを再実行して、衝突領域のサイズを減らすために追加処理を行う:

bzr remerge --merge-type weave --reprocess foobar

remove¶

目的:

ファイルもしくはディレクトリを除外する。

使い方:

bzr remove [FILE…]

オプション:

`--new`	けっしてコミットされなかったファイルのみを除外する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

削除戦略:

`--force`	指定されたファイルがリカバーできないまたは空のディレクトリではなくてもこれらすべてを削除する。
`--keep`	ファイルを削除しない。
`--safe`	ファイルを安全にリカバーできるのであればファイルを削除することだけ行う(デフォルト)。

説明:

このコマンドによってbzrは指定されたファイルへの変更の追跡を止めます。 rebertコマンドで容易に復元できるのであればbzrはこれらのファイルを削除します。オプションもしくはパラメータが与えられなければbzrは追跡されているファイルをスキャンしますがツリーの中で見つからなければそれらの追跡を停止します。

エイリアス:

rm, del

remove-tree¶

目的:

与えられたブランチ/チェックアウトから作業ツリーを除外する。

使い方:

bzr remove-tree [LOCATION]

オプション:

`--force`	コミットされていない変更があっても作業ツリーを除外する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

軽量チェックアウトは作業ツリーと大差ないので、これはそれに対する実行を拒絶します。

作業ツリーを再現するには、”bzr checkout”を使用します。

関連項目:

checkout, working-trees

renames¶

目的:

リネームされたファイルの一覧を表示する。

使い方:

bzr renames [DIR]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

関連項目:

status

resolve¶

目的:

衝突を解消されたものとしてマークする。

使い方:

bzr resolve [FILE…]

オプション:

`--all`	このツリーのすべての衝突を解消する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

2つのブランチの間の変更を結合するためにマージは最善を尽くしますが、人間だけが修正できる種類の問題があります。この問題に遭遇するとき、衝突がマークされます。衝突はコミットする前に何かを修正する必要があることを意味します。

一旦問題を修正すれば、自動的にテキストの衝突を修正したものとしてマークするために”bzr resolve”を使用し、特定の衝突を解消したものとしてマークするためにFILEをresolveします。すべての衝突が解消されたものとしてマークするにはor “bzr resolve –all”を行います。

関連コマンド:

bzr conflicts

エイリアス:

resolved

revert¶

目的:

ファイルを以前のリビジョンに差し戻す。

使い方:

bzr revert [FILE…]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--forget-merges`
	ファイルを変更せずに、未解決のマージマーカーを取り除く。
`--no-backup`	差し戻しされたファイルのバックアップを保存しない。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

指定されたテキストだけを差し戻すファイルのリストを渡します。さもなければ、すべてのファイルが差し戻されます。 ‘–revision’でリビジョンが指定されなければ、最後にコミットされたリビジョンが使用されます。

以前のリビジョンに差し戻さずに、いくつかの変更を除外するには、代わりにmergeを使用します。たとえば、”merge . –revision -2..-3”は-2で導入された変更を除外しますが、 -1で導入された変更には影響を与えません。 hunk-by-hunkベースである変更を除外するには、Shelfプラグインを参照してください。

デフォルトでは、手動で変更されてきたファイルは最初にバックアップされます。 (マージのみで変更されたファイルはバックアップされません。) バックアップファイルの名前には ‘.~#~’ が追加されます。#は番号です。

ファイルを提供する場合、現在のパス名もしくはターゲットリビジョンからのパス名を使用できます。名前でファイルを”undelete”するためにrevertを使用できます。ディレクトリに名前をつけると、そのディレクトリのすべての内容が差し戻されます。

そのリビジョン以降に新しく追加されたファイルは削除されます。適切であればバックアップは維持されます。未知のファイルを持つディレクトリは削除されません。

作業ツリーは未解決のマージされたリビジョンのリストを含みます。これは次のコミットで親として含まれます。通常は、ファイルを差し戻すのと同様にrevertはそのリストをクリーンにします。ファイルが指定されていれば、revertは未解決のマージリストをそのままにしてファイルだけを差し戻します。すべてのファイルを差し戻すがマージの記録を維持するにはツリーのrootで”bzr revert .”を使用し、ファイルの差し戻しを行わずに未解決のマージリストをクリアするには”bzr revert –forget-merges”を使用します。

関連項目:

cat, export

revno¶

目的:

現在のリビジョン番号を表示する。

使い方:

bzr revno [LOCATION]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

これはこのブランチのリビジョン番号と等しいです。

関連項目:

info

root¶

目的:

ツリーのrootディレクトリを表示する。

使い方:

bzr root [FILENAME]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

The rootは.bzrコントロールディレクトリを持つもっとも近い同封ディレクトリです。

send¶

目的:

変更を投稿するためにメールを送るもしくはmergeディレクティブを作成する。

使い方:

bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]

オプション:

`-f ARG, --from=ARG`
	作業ディレクトリを含むブランチよりも、投稿フォームを生成するブランチ。
`--remember`	投稿と公開ブランチを覚える。
`--mail-to=ARG`	このアドレスにリクエストメールを送信する。
`--format=ARG`	指定されたフォーマットを使用する。 “0.9”: バンドルフォーマット 0.9、マージディレクティブ 1。 “4”: バンドルフォーマット 4、マージディレクティブ 2 (デフォルト)。
`--no-bundle`	バンドルをmergeディレクティブに含めない。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-o ARG, --output=ARG`
	mergeディレクティブをこのファイルに書き込む; stdout用に-を使用する。
`-m ARG, --message=ARG`
	メッセージの文字列。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`--no-patch`	mergeディレクティブにプレビューパッチを含めない。
`-v, --verbose`	詳細な情報を表示する。

説明:

mergeディレクティブはmergeリクエストを行うために必要な多くのものを提供します:

実行するマージのマシンが理解できる説明
リクエストされた変更のプレビューであるオプションのパッチ
リビジョンデータのオプションバンドル、ブランチからデータを読み込まずに、mergeディレクトリからの変更を直接適用できるようになります。

–no-bundleが指定されると、public_branchが必要です(また最新でなければなりません)、受け取り手がpublic_branchを使用するマージを実行できるように後で他の人がチェックできるように、知っているのであればpublic_branchを常に含まれていなければなりません。

投稿ブランチのデフォルトは親ですが、上書きできます。提供されれば投稿ブランチと公開ブランチの両方が記録されます。

public_branchがsubmit_branchに知られていれば、その公開と投稿ブランチはマージのインストラクションで使用されます。これはそのローカルミラーに対してpublic_branchを設定すれば、そのミラーは実際の投稿ブランチとして使用できることを意味します。

メールは好きなプログラムで送信されます。 Windowsではこれは透過的です(MAPIが使用される)。 Linuxでは、xdg-emailユーティリティを必要とします。望ましいクライアントが見つからなければ(もしくは使用できなければ)、エディタが使用されます。

特定のメールプログラムを使用するには、mail_client設定オプションを設定します。 (Thunderbird 1.5に関して、これはいくつかのバグに対処します。) 特定のクライアント用にサポートされる値は”claws”、”evolution”、”kmail”、”mutt”、と”thunderbird”; 一般的なオプションは”default”、”editor”、”emacsclient”、”mapi”、と”xdg-email”です。プラグインがサポートされるクライアントを追加することもあります。

メールが送信されている場合、to addressが必要になります。これはコマンドライン、submit_to設定オプションをブランチ自身に設定するか、投稿ブランチでchild_submit_to設定オプションを設定することで提供できます。

現在2つのフォーマットがサポートされています: “4”はリビジョンバンドルフォーマット4 とマージディレクトリフォーマット2です。これは古いフォーマットよりも顕著に速く小さいです。これはBazaar 0.19とそれ以降で互換性があります。これはデフォルトです。 “0.9”はリビジョンバンドルフォーマット0.9とマージディレクティブフォーマット1を使用します。これは0.12 - 0.18と互換性があります。

mergeもしくはpullコマンドを使用することでmergeディレクトリが適用されます。

関連項目:

merge, pull

serve¶

目的:

bzrサーバーを稼働させる。

使い方:

bzr serve

オプション:

`--allow-writes`	デフォルトではサーバーはリードオンリーのサーバーです。 –allow-writesを提供すると提供されるディレクトリとその下の内容への書き込み権限を有効にできる。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--directory=ARG`
	このディレクトリの内容をサーブする。
`--port=ARG`	[hostname:]portnumber形式で指名されたポート上で接続するためにリスンする。 0をポート番号として割り当てるとポートは動的な割り当てになります。デフォルトのポートは4155です。
`--inet`	inetdもしくはsshdからの使用のためにstdin/outでserveする。
`-h, --help`	ヘルプメッセージを表示する。

エイリアス:

server

shelve¶

目的:

いくつかの変更を現在のツリーから一時的に退避する。

使い方:

bzr shelve [FILE…]

オプション:

`--all`	すべての変更を退避する。
`-v, --verbose`	詳細な情報を表示する。
`--list`	退避された変更の一覧を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-m ARG, --message=ARG`
	メッセージの文字列。
`-r ARG, --revision=ARG`
	詳細に関しては”help revisionspec”を参照。

writer:

--plain

プレーンテキスト形式での差分の出力。

説明:

shelveによって変更を一時的に”棚に上げる”、すなわち邪魔にならない場所に置くことができます。 ‘unshelve’コマンドで後で元に戻すことができます。

shelve –listが指定されると、以前退避された変更の一覧が表示されます。

shelveは不適切に混ぜられた変更のいくつかのセットの分離を手助けすることを目的としています。すべての変更を除去したいだけで後で退避する必要がなければ、revertを使用します。一度にすべてのテキストの変更をshelveするには、shelve –allを使用します。

ファイル名が指定されると、それらのファイルの変更のみ退避されます。他のファイルは手つかずのままです。

リビジョンが指定されれば、そのリビジョン以降の変更は退避されます。

複数のアイテムを退避することができ、デフォルトでは、 ‘unshelve’は最近shelveされた変更を復元します。

関連項目:

unshelve

sign-my-commits¶

目的:

与えられたコミッターですべてのコミットに署名する。

使い方:

bzr sign-my-commits [LOCATION] [COMMITTER]

オプション:

`--dry-run`	実際に署名しない。署名されるリビジョンを表示するだけ。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

位置が指定されなければローカルツリーが使用されます。コミッターが指定されなければデフォルトのコミッターが使用されます。

これはすでにシグネチャを持つコミットには署名しません。

split¶

目的:

ツリーのサブディレクトリを個別のツリーに分割する。

使い方:

bzr split TREE

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドは’rich-root’ もしくは ‘rich-root-pack’のようにリッチrootをサポートするフォーマットでターゲットツリーを生み出します。これらのフォーマットは’dirstate-tags’のような初期のフォーマットに変換できません。

TREEの引数は作業ツリーのサブディレクトリになります。そのサブディレクトリは独自のブランチを持つ独立したツリーに変換されます。トップレベルツリーのコミットは新しいサブツリーに適用されません。

status¶

目的:

ステータスの要約を表示する。

使い方:

bzr status [FILE…]

オプション:

`-S, --short`	短いステータスインジケーターを表示する。
`-v, --verbose`	詳細な情報を表示する。
`-V, --versioned`
	バージョン管理されたファイルだけを表示する。
`--no-pending`	未解決のマージを表示しない。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--show-ids`	内部オブジェクトidを表示する。
`-c ARG, --change=ARG`
	指定されたリビジョンで導入された変更を選択する。 “help revisionspec”を参照。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

これはバージョン管理されたファイルと未知のファイルを状態で分類してレポートします。利用可能な状態は次のとおりです:

added: 作業ツリーでバージョン管理されているが以前のリビジョンではない。
removed: 以前のリビジョンでバージョン管理されているが作業コピーでは移動もしくは削除されている。
renamed: 以前のリビジョンから変更されたファイルのパス; テキストも変更されていることがある。これは親ディレクトリがリネームされたファイルを含む。
modified: 以前のリビジョン以降変更されたテキスト。
kind changed: 変更されたファイルの種類(たとえばファイルからディレクトリへ)。
unknown: バージョン管理されていないかつ無視パターンにマッチしない。

無視されるファイルを見るには’bzr ignored’を使用します。ファイルテキストへの詳細な変更に関しては、’bzr diff’を使用します。

–shortもしくは-Sは、Subversionのstatusコマンドに似た、それぞれのアイテムに対するステータスフラグを提供することに注意してください。 svn -qと似たような出力を得るには、bzr status -SVを使用します。

引数が指定されなければ、作業ディレクトリ全体のステータスが示されます。さもなければ、指定されたファイルもしくはディレクトリのステータスのみが報告されます。ディレクトリが渡されれば、そのディレクトリ内部のすべてに関するステータスが報告されます。

1つのリビジョンの引数が渡されれば、ステータスはそのリビジョンに対して 2つの引数の場合は2つのリビジョンの間で算出されます。

エイリアス:

st, stat

関連項目:

diff, revert, status-flags

switch¶

目的:

チェックアウトのブランチを設定してupdateする。

使い方:

bzr switch TO_LOCATION

オプション:

`--force`	ローカルコミットが失われていても切り替える。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

軽量チェックアウトに対して、これは参照されているブランチを変更します。重量チェックアウトに対して、これはローカルコミットがなく、バインドされたブランチがないことを確認して、ローカルブランチを新しいロケーションのミラーにしてそれにバインドします。

両方の場合において、作業ツリーはupdateされコミットされてない変更はマージされます。ユーザーは望むのであればcommitもしくはrevertできます。

マージの追加にはswithを使用する前にcommitもしくはrevertする必要があります。

swithするブランチへのパスは現在のブランチの親ディレクトリに対して相対的に指定できます。たとえば、現在/path/to/branchのチェックアウトの中にいるのであれば ‘newbranch’を指定すれば/path/to/newbranchでのブランチが発見されます。

ローカルに設定されていない限りバインドされたブランチはマスターブランチのニックネームを使用します。この場合、switchを行うとローカルのニックネームはマスターのものに更新されます。

tag¶

目的:

リビジョンを名づけっるタグを作成、削除もしくは修正する。

使い方:

bzr tag TAG_NAME

オプション:

`--force`	既存のタグを置き換える。
`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-d ARG, --directory=ARG`
	タグを設置するブランチ
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`--delete`	置き換えるよりもタグを削除する。

説明:

タグはリビジョンに人間が理解できる名前を与えます。 -r (–revision)オプションをとるコマンドは-rtag:Xに渡されます。 Xは以前作成されたタグです。

タグはブランチに保存されます。 branch、push、pullもしくはmergeを行うときタグはあるブランチから他のブランチにコピーされます。

–forceを渡さない限り、既存のタグ名を与えるとエラーになります。この場合新しいリビジョンを示すようにタグは移動します。

タグをリネームする(名前を変更するが同じリビジョンで維持する)には、 bzr tag new-name -r tag:old-name と bzr tag --delete oldname を実行します。

関連項目:

commit, tags

tags¶

目的:

タグの一覧を表示する。

使い方:

bzr tags

オプション:

`--sort=ARG`	異なる基準でタグをソートする。 “alpha”: 辞書式でタグをソートする(デフォルト)。 “time”: 年代順でタグをソートする。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-d ARG, --directory=ARG`
	タグが表示されるブランチ。
`--show-ids`	内部オブジェクトidを表示する。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドはこれらが参照するタグ名とリビジョンのテーブルを表示します。

関連項目:

tag

testament¶

目的:

リビジョンのtestament(署名のフォーム)を表示する。

使い方:

bzr testament [BRANCH]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--long`	長いフォーマットのtestamentを生成する。
`--strict`	厳密なフォーマットのtestamentを生成する。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

unbind¶

目的:

現在のチェックアウトを通常のブランチに変換する。

使い方:

bzr unbind

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

unbindした後で、ローカルブランチは独立したものとして見なされその後のコミットはローカルのみで行われます。

関連項目:

bind, チェックアウト

uncommit¶

目的:

最後にコミットされたリビジョンを削除する。

使い方:

bzr uncommit [LOCATION]

オプション:

`--dry-run`	実際には変更しない。
`-v, --verbose`	詳細な情報を表示する。
`-h, --help`	ヘルプメッセージを表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--force`	すべての質問にyesと答える。
`--local`	チェックアウトのときローカルブランチからコミットのみを削除する。
`-r ARG, --revision=ARG`
	詳細は”help revisionspec”を参照。

説明:

–verboseは削除されているものを表示します。 –dry-runはすべてのモーションを経験しますが、実際には何も削除しません。

–revisionが指定されると、指定されたリビジョンでブランチをそのままにするためにリビジョンをuncommitします。たとえば、”bzr uncommit -r 15”はリビジョン15でのブランチをそのままにします。

uncommitは新しいコミットの準備ができている作業ツリーをそのままにします。唯一行われる変更はコミット以前に存在していた追加マージをリストアすることです。

関連項目:

commit

unshelve¶

目的:

shelveされた変更を復元する。

使い方Usage:

bzr unshelve [SHELF_ID]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

アクション:

`--apply`	変更を適用してshelfから削除する。
`--delete-only`	変更を適用せずにそれらを削除する。
`--dry-run`	編子を表示するがそれらを適用もしくは除外しない。

説明:

デフォルトでは、最近shelveされた変更が復元されます。んまでパッチを指定したとしてもそれらの変更が代わりに復元されます。変更がお互いに依存しないときにこれはもっとも良く機能します。

関連項目:

shelve

update¶

目的:

ブランチにコミットした最新コードにツリーを更新する。

使い方:

bzr update [DIR]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

説明:

このコマンドは作業ツリーでマージを実行し、衝突を生成することがあります。ローカルの変更がある場合、updateを完了させるために updateの後でそれらをコミットする必要があります。

ローカルの変更を破棄したい場合、updateの後で’bzr commit’の代わりに ‘bzr revert’を使用できます。

エイリアス:

up

関連項目:

pull, status-flags, working-trees

upgrade¶

目的:

ブランチのストレージを現在のフォーマットにアップグレードする。

使い方:

bzr upgrade [URL]

オプション:

`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`-h, --help`	ヘルプメッセージを表示する。

ブランチのフォーマット:

--format=ARG        このブランチのフォーマットを指定する。"help formats"を参照。
--1.12-preview      ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
--1.12-preview-rich-root
                    rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
--1.6               スタックをサポートするリポジトリに基づいたブランチとパック。
--1.6.1-rich-root   スタックとリッチなrootデータをサポートするリポジトリに基づいた
                    ブランチとパック(bzr-svnに必要)。
--1.9               btreeインデックスを使用するリポジトリに基づいたブランチとパック
--1.9-rich-root     btreeインデックスとリッチrootデータを使用する
                    リポジトリに基づいたブランチとパック(bzr-svnに必要)。
--default           0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用しますが
                    bzr < 0.92では読むことができません。
                    以前はknitpack-experimentalと呼ばれていました。
                    詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
--development       現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
--development-subtree
                    現在の開発フォーマットで、subtreeバリアント。
                    データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
                    フォーマットリポジトリに変換できる。
                    このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
                    使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
                    repo.html をご覧いただくようお願いします。
--dirstate          0.15の新しいフォーマット: 速いローカルオペレーション。
                    ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
--dirstate-tags     0.15の新しいフォーマット: 速いローカルオペレーションで
                    ネットワークオペレーションに関するスケーリングを改善。
                    タグのサポートを追加。bzr < 0.15とは互換性がない。
--knit              knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
--metaweave         0.8での暫定フォーマット。knitよりも遅い。
--pack-0.92         0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
                    互換性のあるデータを持つパックベースのフォーマット。
                    0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
                    以前はknitpack-experimentalと呼ばれていた。
                    詳細な情報に関しては、 http://doc
                    .bazaar-vcs.org/latest/developers/packrepo.html を参照。
--rich-root         1.0の新しいフォーマット。ツリーrootのベターな扱い。
                    bzr < 1.0と互換性がない。
--rich-root-pack    1.0の新しいフォーマット: rich-rootデータをサポートする
                    pack-0.92のバリアント(bzr-svnに必要)。
--weave             0.8以前のフォーマット。knitよりも遅く
                    チェックアウトもしくは共用リポジトリをサポートしない。

説明:

ときどきこのコマンドを実行するにcheckコマンドもしくはbzrの開発者がアドバイスすることがあります。デフォルトフォーマットが変更されたときアップグレードする他のオペレーションの実行中に警告されることもあります。

関連コマンド:

check

version¶

目的:

bzrのバージョンを表示する

使い方:

bzr version

オプション:

`--short`	バージョン番号だけを表示する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告だけ表示する。
`-h, --help`	ヘルプメッセージを表示する。

version-info¶

目的:

このツリーに関するバージョン情報を表示する。

使い方:

bzr version-info [LOCATION]

オプション:

`--all`	すべての入手可能な情報を含める。
`-v, --verbose`	詳細な情報を表示する。
`--check-clean`	ツリーがクリーンであるかチェックする。
`--include-history`
	リビジョンの履歴を含める。
`-q, --quiet`	エラーと警告のみを表示する。
`--template=ARG`	出力用のテンプレート。
`--include-file-revisions`
	それぞれのファイルに対する最終リビジョンを含める。
`-h, --help`	ヘルプメッセージを表示する。

フォーマット::

`--format=ARG`	出力フォーマットを選択する。
`--custom`	カスタムテンプレートベースのフォーマットでのバージョン情報。
`--python`	Pythonフォーマットでのバージョン情報。
`--rio`	RIOフォーマット(シンプルなテキスト)でのバージョン情報(デフォルト)。

説明:

バージョンに関する情報をアプリケーションのソースコードに追加するためにこのコマンドを使用できます。出力のフォーマットはサポートされているもの1つかテンプレートに基づいてカスタマイズされたものです。

例:

bzr version-info --custom \
  --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n"

現在のリビジョン番号を含むフォーマットされた文字列でCヘッダファイルを生成します。テンプレートでのサポートされた他の変数は次のとおりです:

{date} - 最終リビジョンの日付

{build_date} - 現在の日付

{revno} - リビジョン番号

{revision_id} - リビジョンid

{branch_nick} - ブランチのニックネーム

{clean} - ソースコードがコミットされていない変更を含むときは0でそれ以外は1

whoami¶

目的:

bzrのユーザーidを表示もしくは設定する。

使い方:

bzr whoami [NAME]

オプション:

`--email`	Eメールアドレスのみ表示する。
`-v, --verbose`	詳細な情報を表示する。
`-q, --quiet`	エラーと警告のみを表示する。
`--branch`	グローバルの代わりに現在のブランチ用のIDを設定する。
`-h, --help`	ヘルプメッセージを表示する。

例:

現在のユーザーのEメールを表示する:

bzr whoami --email

現在のユーザーを設定する:

bzr whoami "Frank Chu <fchu@example.com>"

Bazaarユーザーリファレンス¶

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

概念¶

ブランチ¶

チェックアウト¶

クリスクロス¶

ストレージフォーマット¶

パターン¶

リポジトリ¶

ルール¶

紹介¶

ファイル¶

ルールのパターン¶

スタンドアロンのツリー¶

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

作業ツリー¶

リスト¶

認証の設定¶

Intent¶

認証の定義¶

ファイルのフォーマット¶

例¶

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

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

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

計画的な強化¶

バグトラッカーの設定¶

Launchpad¶

bugzilla_<tracker_abbreviation>_url¶

trac_<tracker_abbrevation>_url¶

bugtracker_<tracker_abbrevation>_url¶

構成設定¶

環境変数の設定¶

BZR_EMAIL¶

BZR_PROGRESS_BAR¶

BZR_SIGQUIT_PDB¶

BZR_HOME¶

BZR_SSH¶

BZR_PDB¶

BZR_REMOTE_PATH¶

BZR_EDITOR¶

BZR_PLUGIN_PATH¶

BZRPATH¶

設定ファイル¶

設置場所¶

一般的なフォーマット¶

コメント¶

セクション変数¶

変数のポリシー¶

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

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

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

変数の共通オプション¶

email¶

editor¶

check_signatures¶

create_signatures¶

recurse¶

gpg_signing_command¶

bzr_remote_path¶

smtp_server¶

smtp_username, smtp_password¶

mail_client¶

submit_branch¶

public_branch¶

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

append_revisions_only¶

parent_location¶

push_location¶

bound_location¶

bound¶

衝突のタイプ¶

テキストの衝突¶

内容の衝突¶

重複したパス¶

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

見つからない親¶

親を削除する¶

パスの衝突¶

親のループ¶

Bazaarユーザーリファレンス ¶

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

概念 ¶

リスト ¶

コマンド ¶