Bazaarユーザーリファレンス

Version:1.11
Generated:2009-01-09

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

このマニュアルは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種類の認証があります:

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

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

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

ホストに対して認証するために HTTPHTTPS は(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: 空にできます (定義の残りは任意のスキームに対して使用できることを意味する)、 SFTPbzr+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.netbzr.sf.net にマッチしない)。
  5. port はリクエストされたURLに含まれる場合(正確にマッチする場合のみ)マッチします。
  6. 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_encodingverify_certificates フィールドは認識されますが 実際の実装では無視されます。

バグトラッカーの設定

コミットを行うとき、その変更によって修正されたバグに関するメタデータは –fixes オプションを使用することで記録されます。 それぞれのバグが修正されたものとしてマークされるために、エントリーが ‘<url> <status>’ を述べる ‘bugs’ リビジョンプロパティに含まれます。 (現在サポートされる status の値は fixed. だけです) Launchpadの中心バグトラッカー用のサポートは組み込まれています。 他のバグトラッカーに関して、正しいURLが記録されるように設定が予め要求されます。

Launchpadに加えて、BazaarはBugzillaとTracに適切なURLの生成を直接サポートします。 プロジェクトが異なるバグトラッカーを使用するのであれば、そのサポートを追加するのは簡単です。 BugzillaもしくはTracを使用しているのであれば、 バグトラッカーの基底URLを格納する設定変数を設定することだけが必要です。 これらのオプションは bazaar.confbranch.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 によって設定され、 環境変数 VISUALEDITOR によって上書きされます。

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 プラグインを処理しない。
--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:(ネイティブ) ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
1.12-preview-rich-root:
 (ネイティブ) 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”の名前になることができます。 何も渡されなければ、拡張子かrフォーマットを見つけようとします。 拡張子が見つからなければディレクトリにエクスポートします(–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-namebzr 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 2.0 移行ガイド

このページ