.. This file is autogenerated from the output of .. bzr help topics .. bzr help commands .. bzr help .. .. Generation time: 2009-01-09 07:03:09 +0000 ########################## Bazaarユーザーリファレンス ########################## :Version: 1.11 :Generated: 2009-01-09 .. contents:: :depth: 2 ----- このチュートリアルについて ########################## このマニュアルはBazaarのオンラインヘルプから生成されました。オンラインヘルプのシステムを利用するためには次のコマンドを試してください。よく使われるコマンドの一覧を含めて紹介します:: bzr help トピックの一覧とそれぞれの要約:: bzr help topics コマンドの一覧とそれぞれの要約:: bzr help commands 特定のトピックもしくはコマンドに関する詳細な情報:: bzr help topic-or-command-name 次のウェブサイトはBazaarに関する詳細な情報を提供します: :ホームページ: http://www.bazaar-vcs.org/ :公式ドキュメント: http://doc.bazaar-vcs.org/ :Launchpad: https://launchpad.net/bzr/ 概念 #### ブランチ ========= ブランチは、すべての履歴を含む、プロジェクトの状態で構成されます。すべてのブランチは関連づけされたリポジトリ(ブランチの履歴が保存される場所)を持ちますが、複数のブランチは同じリポジトリを共有することもあります(共用リポジトリ)。ブランチはコピーしたりマージしたりできます。関連コマンド:: init ディレクトリをバージョン管理されたブランチに変更する。 branch ブランチの新しいコピーを作成する。 merge 3方向マージ (3-way merge) を実行する。チェックアウト ============== チェックアウトはブランチに結びつけられたソースツリーなので、ソースツリーにコミットするときに、コミットの内容はブランチに格納されます。必要になるまでBazaarの分散型機能の一部を無視して、よりシンプルに、集中型のワークフローを利用できます。共用リポジトリでチェックアウトを利用することはSVNもしくはCVSでの作業とよく似ていますが、同じ制限を持ちません。そしてチェックアウトを利用することで望むワークフローがなんであれ他の人もプロジェクトに取り組むことができます。チェックアウトはbzr checkoutコマンド("help checkout"を参照)によって作成されます。これに別のブランチへのリファレンスを渡し、マスターブランチからのチェックアウトを作成したブランチへのリファレンスをまだ含むローカルコピーを作成します。何かコミットをすればこれらは他のブランチで最初に作成されます。これによって作業内容のインスタントミラーが作成されるもしくはそれぞれの開発者が共同で作業して他の人の変更を継続的に統合するロックステップ開発を円滑にします。しかしながらチェックアウトはまだBazaarの第一級のブランチで、すべての履歴をローカルで保存できます。第一級のブランチがあるので、ローカルにコミットすることもできます。たとえば、ネットワーク接続による一時的な遅延を回避したいのであれば、ローカルでもコミットできます。これを行うには --local オプションを使います。次にローカルではないコミットを行うときにすべてのローカルコミットはマスターブランチに行われます。共用ブランチからのチェックアウトを使用しているとき、周期的に他の人による変更をすべてpullしたくなります。これは"update"コマンドによってできます。ローカルではないコミットの前に変更が適用される必要がありますが、 Bazaarは変更が存在することを伝え必要なときにこのコマンドを使うように提示します。 checkoutコマンドに--lightweightフラグを渡すことで"軽量"チェックアウトを作成することも可能です。第一級のブランチではなく、主に作業ツリーで構成されるという点で、軽量チェックアウトはSVNのチェックアウトにより近いです。履歴のオペレーションはマスターブランチに問い合わせをしなければならないので、ネットワーク接続が関わる場合遅くなる可能性があることを意味します。また、ローカルブランチを持たないので、ローカルでコミットできません。マスターブランチに高速で信頼性のあるアクセス権限があるときに軽量チェックアウトは最も良く動作します。マスターブランチが同じディスクもしくはLAN上にあれば、(ブランチのコピーの更新だけが必要なので) リビジョンを変更するどのコマンドでも軽量ブランチは重量ブランチよりも速くなることを意味します。一般的に重量チェックアウトは速いですが、マスターブランチが同じディスク上のあるときは、顕著な違いはありません。チェックアウトの別の使い方はブランチを格納するツリーなしのリポジトリで使うことです。ここでは異なるブランチに取り組むときチェックアウトが指定するマスターブランチを切り替えることで 1つの作業ツリーだけを維持します。明確にチェックアウトにコミットするにはマスターブランチへの書き込み権限が必要です。マスターブランチはsftp://といった書き込み可能なプロトコルでアクセスしなければならないので、相手方で書き込み権限をもたなければならないことを意味します。チェックアウトはローカルファイルシステムでも機能するので、すべての問題はファイルのパーミッションです。 "bind"コマンド("help bind"を参照)を使用することでチェックアウトのマスターを変更できます。これによってコミットが送信される位置が変更されます。 bindコマンドはブランチをheavyチェックアウトに変換するためにも使用できます。すべてのコミットがローカルで行われるようにheavyチェックアウトを通常のブランチに変換したい場合、 "unbind" コマンドを使用できます。関連コマンド:: checkout チェックアウトを作成する。軽量チェックアウトを得るには --lightweight を渡す update マスターブランチの変更をあなたのチェックアウトにpullする commit マスターブランチに送信されるコミットを行う。重量チェックアウトであれば --localオプションによってマスターにコミットを送信せずにチェックアウトにコミットされます bind 送信されるチェックアウトにコミットされるマスターブランチを変更する unbind コミットがローカルだけで行われるように重量チェックアウトをスタンドアロンのブランチに変換するクリスクロス ============ ブランチの履歴のクリスクロス(Criss-cross)は通常期待されるよりも多くのコンフリクトを出すデフォルトのマージテクニックを必要とします。複雑なマージの場合、 ``bzr merge --lca`` もしくは ``bzr merge --weave`` ではよりよい結果になるかもしれません。作業ツリーを ``bzr revert`` して再度マージしたいと願うかもしれません。代わりに、特定の衝突しているファイル上で ``bzr remerge`` を使います。 2つのブランチが同じものをマージしてお互いにマージし合う場合、もしくは2つのブランチが同時にお互いをマージする場合、クリスクロスはブランチの中で発生します。それぞれのブランチが目的の集中型ブランチからもしくはそのブランチからのみマージすることでこれらを回避できます("star topology")。マージが動作する方法のためクリスクロスは問題を引き起こします。 Bazaarのデフォルトマージは三方向マージです; OTHERをTHISにマージするには比較、BASE用の基本を見つけなければなりません。 BASEを利用することで、THISとOTHERの違いが行を追加するワンサイドか、行を削除する別のサイドによるのかを決定できます。クリスクロスはベースに関してよい選択肢がないことを意味します。最近のマージポイントを選択することはワンサイドの変更を少し廃棄してしまう可能性があります。 (Bazaarが行う)古いマージポイントを選択することは余分な衝突が発せられることを意味します。 ``weave`` マージタイプはこの問題の影響を受けません。このタイプは違いの原因を決定するためにベースのリビジョンの代わりに行を起点とする検出方法を利用するからです。ストレージフォーマット ======================= 古いクライアントが不正にデータにアクセスしないことを保証するために、 Bazaarのポリシーでは新しい機能が新しいメタデータを追加する必要があるときに新しいフォーマットを導入することにしています。新しいストレージフォーマットはパフォーマンスとスケーラビリティを改善するために導入することもあります。フォーマットを選ぶために次のガイドラインを利用します(条件がtrueであると同時に停止): * 既存のプロジェクトに取り組んでいる場合、プロジェクトが利用しているものを使用します。 (デフォルトでBazaarはあなたの代わりにこれを行います)。 * Subversionリポジトリと連携するbzr-svnを利用している場合は、 1.9-rich-rootを使用します。 * 大きなツリー(5000以上のパス)もしくは深い履歴(5000以上のリビジョン)を持つプロジェクトに取り組んでいるのであれば、1.9を使用します。 * さもなければ、デフォルトのフォーマットを使用します。大抵のプロジェクトはこれで十分です。 (ディストロのパッケージを利用しているなどで)最新のBazaarを利用できない開発者がいるのであれば、それに応じてガイドラインを調整してください。たとえば、プロジェクトがBazaar 1.7を標準化している場合、1.9の代わりに1.6を選ぶことが必要です。注: 現在サポートされるフォーマットの多くは2つのバリアントを持ちます: plainのものとrich-rootのものです。後者はツリーのrootに関する追加フィールドを含みます。 rich-rootフォーマットを利用する際にパフォーマンスコストはありませんが rich-rootフォーマットからの変更をplainフォーマットに簡単にマージできません。結果として、すべての投稿者がほぼ同時にリポジトリをアップグレードする必要があるので、プロジェクトをrich-rootフォーマットに移行させるには調整が必要です。 (これまでのところrich-rootフォーマットをデフォルトにすることを遅らせてきた理由です。将来の適切な時期にこれを行います。) 現在サポートされるフォーマットの完全なリストに関しては ``bzr help current-formats`` を参照してください。利用可能で実験上もしくは廃止されたフォーマットに関しては ``bzr help other-formats`` を参照してください。パターン ======== Bazaarはさまざまな時点でマッチするファイルを使用します。たとえば、 ``add`` コマンドは無視するパターンにマッチするファイルとスキップしプリファレンスはルールパターンを使用するファイルに関連づけできます。パターン構文は下記のとおりです。パターン上のトレーリングスラッシュは無視されます。パターンがスラッシュを含むもしくは正規表現である場合、ブランチのroot全体から比較されます。さもなければ、これはパスの最後のコンポーネントのみと比較されます。 rootディレクトリの中のファイルのみにマッチさせるには'./'を用意します。絶対パスを指定するパターンは許可されていません。パターンは次のようなglobのワイルドカードを含むことができます:: ? - '/'以外の単独文字にマッチする * - '/'以外の0かそれ以上の文字数にマッチする /**/ - パスの中のゼロかそれ以上のディレクトリにマッチする [a-z] - 文字のグループの範囲内からの単独の文字にマッチするパターンはPythonの正規表現にもなります。正規表現のパターンは 'RE:' の接頭辞で始まる正規表現で識別されます。正規表現のパターンは名前つきもしくは番号つきのグループを含むことはできません。リポジトリ =========== Bazaarのリポジトリはコミットされた情報が保存される場所です。すべてのブランチと関連づけされたリポジトリが1つ存在します。リポジトリは一種のデータベースです。通常、パフォーマンスのためにBzrはこれを自動的に維持しますが、ある状況(たとえば短い期間にとても多くのコミットを行う) データベースのインデックスを最適化するようbzrに求めるとよいでしょう。これは'bzr pack' コマンドによって行われます。デフォルトでは 'bzr init' を実行するだけで新しいブランチの中でリポジトリが作成されますが、同じ位置で情報を共有するために複数のブランチを許可する共用リポジトリを作成することが可能です。新しいブランチが作成されたとき使用できる共用リポジトリが存在するかどうかを最初に確認します。同じプロジェクトのブランチが1つのリポジトリを共有するとき、一般的にスペースが大きく節約されます。 (たとえばリポジトリの範囲内でブランチを作成するなどの)いくつかのコマンドに対してこれは大きな時間の節約になります。共用リポジトリを作るには、init-repositoryコマンド(もしくはエイリアスのinit-repo)を使います。このコマンドは作成するリポジトリの位置をとります。このことは'bzr init-repository repo'によって'repo'という名前のディレクトリが作成されその中に共用リポジトリが格納されることを意味します。このディレクトリの中に作成された新しいブランチはストレージ用にそれを使用します。 1つ以上のプロジェクトのブランチを作成するときに1つのリポジトリを作成することはよい考えです。これは開発を行っている作業領域と、ホスティングプロジェクト用のサーバー領域の両方にあてはまります。後者の場合、作業ツリーなしのブランチが欲しいことは良くあります。ブランチのファイルは直接編集されないので作業ツリー用にディスクスペースを使い切る必要はありません。作業ブランチを持たないリポジトリを作成するには、 'init-repository'に'--no-trees'オプションを渡します。関連コマンド:: init-repository 共用リポジトリを作成する。新しいブランチが作業ツリーを作成しないものを作成するには--no-treesを使用する。ルール ======= 紹介 ----- ルールはiniファイルフォーマットで定義されます。セクションはファイルのglobパターンでそれぞれのセクションの内容はそのパターンにマッチするファイル用のプリファレンスです。例です:: [name *.bat] eol = dos [name *.html] keywords = escape これらのようなプリファレンスは選択されたブランチの中で選択されたファイル用にカスタムのふるまいを提供したいコマンドとプラグインに役立ちます。ファイル --------- すべてのブランチ用のデフォルトルールはオプションの ``BZR_HOME/rules`` ファイルで定義されます。ルールのパターン ----------------- パターンは順序づけされ1つマッチすると共に検索は停止します。結果として、より明確なパターンをファイルのトップの方に置くべきです。ルールパターンは無視パターンとまったく同じ仕様を利用します。詳細は ``bzr help patterns`` を参照してください。注: 角かっこを含むパターンはそれらが正しく解析されるようにクォートで囲まなければなりません。スタンドアロンのツリー ======================= スタンドアロンのツリーは関連リポジトリを持つ作業ツリーです。他に依存していないので、これは独立して利用できるブランチです。 (bzr initを通して)スタンドアロンのツリーの作成は既存のプロジェクトをバージョン管理の元に置くための最も速い方法です。関連コマンド:: init ディレクトリをバージョン管理下にあるブランチにする。同期化がずれているブランチ ========================== チェックアウト、ツリーもしくはブランチを軽量ブランチに再設定するとき、ローカルのブランチを破壊しなければなりません。 (チェックアウトに関して、これはキャッシュとして最初に提供するローカルブランチです。) 破壊されるブランチが同じ最終リビジョンを持たなければ、軽量用チェックアウト用の新しい参照ブランチ、データが失われる可能性があるので、 Bazaarは拒否します。この取り組み方は *なぜ* ブランチの同期がずれるのかによります。チェックアウトが手元にありローカルコミットを行う場合、 "bzr update"(とおそらくは"bzr commit")を実行することで再び同期化できます。ブランチが手元にあり、リモートブランチが時代遅れになっている場合、 "bzr push"を使用してローカルの変更をプッシュできます。ローカルブランチが時代遅れであれば、"bzr pull"をできます。両方のブランチに変更があれば、変更をマージ、コミットしてプッシュできます。変更の一部が便利でなければ、"push --overwrite"もしくは代わりに"pull --overwrite"できます。作業ツリー =========== 作業ツリーはディスク上に設置されたブランチのコンテンツなのでファイルを見て編集できます。作業ツリーはブランチに変更を行う場所なので、作業ツリーの現在の状態をコミットするとき、コミットに記録されるレコードです。ブランチをリモートシステムにプッシュするとき、作業ツリーは作成されません。ファイルがすでに存在すれば、ファイルは更新されません。ブランチの情報は更新され作業ツリーは時代遅れとしてマークされます。リモートの作業ツリーを更新するのは難しいです。アンコミットされた変更が存在するもしくは更新によってリモートで扱うのが難しい内容の衝突が引き起こされるからです。作業ツリーなしのブランチがあれば作業ツリーを作成するために 'checkout' コマンドを使用できます。ブランチから 'bzr checkout .' を実行すると作業ツリーが作成されます。リモートでブランチが更新されると、そのディレクトリの中で'bzr update'を実行することで作業ツリーを更新できます。望まない作業ツリーを持つブランチがある場合、安全であれば'remove-tree'コマンドはツリーを除外します。ブランチにプッシュするとき更新されないリモート作業ツリーに関する警告を回避することでこれは可能です。これは'--no-trees'リポジトリ('bzr help repositories'を参照)に取り組むときにも便利です。プッシュするリモートマシン上で作業ブランチを持ちたい場合、 pushするごとにリモートブランチで'bzr update'を実行するか、 pushの間にツリーを更新する他の方法を使用できます。 rsyncを使用してpushと同じように作業ツリーを更新する'rspush'プラグインが存在します。それぞれのプッシュの後で'bzr update'を自動的に実行する'push-and-update'プラグインも存在します。便利なコマンド:: checkout ブランチが作業ツリーを持たないときにそれを作成する。 remove-tree これを行うときに安全であるときにブランチから作業ツリーを除外する。 update 作業ツリーが関連ブランチから同期がずれているときこのコマンドによってブランチにマッチするツリーが更新される。 .. _formats: `ストレージフォーマット`_ .. _standalone-trees: `スタンドアロンのツリー`_ .. _sync-for-reconfigure: `同期化がずれているブランチ`_ .. _working-trees: `作業ツリー`_ リスト ####### 認証の設定 =========== Intent ------ ``authentication.conf`` ファイルの中で多くの異なる認証ポリシーは記述できますが特定のユーザーはすべてのブランチ用のユーザーとパスワードを指定しなくても自分のニーズをカバーするわずかな定義だけが必要です。このファイルの中で見つかる定義は与えられたurl用のクレデンシャルを見つけるために使われます。一般的に同じクレデンシャルを必要とするリモートサーバーの周辺で宣言を分類することで可能な限り多くのブランチに対してクレデンシャルを使用できます。異なるサーバーによって使用されるクレデンシャルを宣言することも可能です。 intentは維持を最少にするためにこのファイルを可能な限り小さくするものです。このファイルの中で関連のクレデンシャルが宣言されるとパスワード(セキュリティハザード)を埋め込まずもしくは(他の人とURLの共有を有効にする)ユーザーなしでブランチのURLを利用できます。次のURLよりも:: bzr branch ftp://joe:secret@host.com/path/to/my/branch シンプルになります:: bzr branch ftp://host.com/path/to/my/branch ``authentication.conf`` ファイルを作成したことを前提とします:: [myprojects] scheme=ftp host=host.com user=joe password=secret 認証の定義 ----------- bzrによってサポートされるさまざまなスキームによって使用される2種類の認証があります: 1. ユーザーとパスワード ``FTP`` は ``host`` 用に (``user`` 、 ``password``) を必要とします。 ``SFTP`` は認証用にパスワードもしくはホストキーを使用できます。しかしながら、sshエージェントはベターで、よりセキュアな解決方法です。独自のセキュアではない方法を提供しないことにします。 2. ユーザー、領域とパスワードホストに対して認証するために ``HTTP`` と ``HTTPS`` は(``user, realm, password``)を必要とします。 ``.htaccess`` ファイルを利用することで、たとえば、任意の ``host`` に対して (``user, realm, password``) をいくつか定義することが可能です。ですので本当に必要なのは (``user``, ``password``, ``host``, ``path``)です。 ``realm`` は定義で考慮されませんが、bzrにパスワードを催促される場合表示されます。 ``HTTP proxy`` は適切なポートを指定することで ``HTTP`` (もしくは ``HTTPS``) として扱うことができます。すべてのスキームを考慮するには、パスワードは認証定義の一式 (``scheme``, ``host``, ``port``, ``path``, ``user``, ``password``) から推定されます。 * ``scheme``: 空にできます (定義の残りは任意のスキームに対して使用できることを意味する)、 ``SFTP`` と ``bzr+ssh`` はここでは使うべきではありません。代わりに ``ssh`` が使われるべきです。これが認証に関して本当のスキームだからです。 * ``host``: 空にできます (ホスト用のデフォルトとして振る舞う), * ``port`` は空にできます (ホストが同じスキームに対していくつかのサーバーを提供するときに便利)、数値の値のみが許可され、サーバーがスキームの標準ポートとは異なるポートを使用するときのみにこれは使用されます。 * ``path``: 空にできます (FTPもしくはSFTPはこれを使用しません), * ``user``: 空にできます (デフォルトでは ``bzr`` はpythonの ``getpass.get_user()`` を使用), * ``password``: 常にパスワードをプロンプトで入力する方が望ましいのであれば空にできます。任意のURLに対して、複数の定義を提供できます。 bzrは次のルールに従って (``user`` [, ``password``]) を選択します: 1. 最初にマッチするものが優先される 2. すべてにマッチする空のフィールド 3. デコレータがリクエストされたURLに使用されていても ``scheme`` はマッチします。 4. ``host`` は正確にマッチするか '.' で始まる場合、ドメインとしてふるまいます。 (``project.bzr.sf.net`` は ``.bzr.sf.net`` にマッチしますが ``projectbzr.sf.net`` は ``bzr.sf.net`` にマッチしない)。 5. ``port`` はリクエストされたURLに含まれる場合(正確にマッチする場合のみ)マッチします。 6. ``path`` はリクエストされたURLに含まれる場合マッチします (そして上記のルール #2 によって、空のパスは任意の提供されたパスにマッチします)。ファイルのフォーマット ---------------------- `設定ファイル`_ 用の一般ルールは変数ポリシー意外に当てはまります。 .. _設定ファイル: #configuration-settings それぞれのセクションで認証の定義を記述します。セクションの名前は任意の文字列で、 ``DEFAULT`` の値のみが保存され *最後* のセクションとして現れます。それぞれのセクションは次の内容を定義すべきです: * ``user``: 使用されるログイン名それぞれのセクションは次の内容を定義できます: * ``host``: リモートサーバー * ``port``: サーバーがリスンしているポート番号 * ``path``: ブランチの位置 * ``password``: パスワード例 --- 外部でホストされた個人プロジェクト ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ すべての接続は同じ ``user`` で行われ (デフォルトのbzrのものが適切でない場合のためのリモートの接続) パスワードはいくつかの例外とともに常に催促されます:: # hobby.netのPetプロジェクト [hobby] host=r.hobby.net user=jim password=obvious1234 # ホームサーバー [home] scheme=https host=home.net user=joe password=1essobV10us [DEFAULT] # ローカルユーザーがbarbazで、すべてのリモートサイト上ではfoobarとして user=foobar ソースホスティングプロバイダ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ shp.net(仮想)ドメインにおいて、それぞれのプロジェクトは独自のサイトを持ちます:: [shpnet domain] # sftpを使用するが、sshは認証用に使用される scheme=ssh # '.' は 'shp.net' だけがマッチしないことを保証する host=.shp.net user=joe # bzrはsftp用のパスワードの提供を保証しません # パスワードをインタラクティブに入力したくなければ # sshエージェントを使用することを考えてください(pageant, ssh-agent、など) HTTPS、SFTPサーバーとプロキシ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ company.comにおいて、サーバーのホスティングリリースは統合ブランチの背後にはプロキシがあり、 2つのブランチは異なる認証ポリシーを使用します:: [reference code] scheme=https host=dev.company.com path=/dev user=user1 password=pass1 # devサーバー上の開発ブランチ [dev] scheme=ssh # bzr+sshとsftpはここで利用可能 host=dev.company.com path=/dev/integration user=user2 # プロキシ [proxy] scheme=http host=proxy.company.com port=3128 user=proxyuser1 password=proxypass1 計画的な強化 ------------- 次の内容はまだ実装されていませんが進行中の作業の一部として計画されています: * ``password_encoding`` フィールドの追加は次のとおりです: - さまざまな難読化のエンコーディング(たとえばbase64)でパスワードを保存する。 - パスワードの保存をプラグインに委譲する(たとえば.netrc)。 * ユーザーがユーザー名もしくはパスワードの入力を催促されたらクレデンシャルを更新する。 * ``HTTPS`` 用に ``verify_certificates`` フィールドを追加する。 ``password_encoding`` と ``verify_certificates`` フィールドは認識されますが実際の実装では無視されます。バグトラッカーの設定 ===================== コミットを行うとき、その変更によって修正されたバグに関するメタデータは --fixes オプションを使用することで記録されます。それぞれのバグが修正されたものとしてマークされるために、エントリーが ' ' を述べる '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__url ----------------------------------- 存在するのであれば、Bugzillaのバグトラッカーの位置はによって参照されます。そのバグトラッカーのバグをそのコミットで修正されたものとしてマークするためにはこのオプションは ``bzr commit --fixes`` と一緒に使用できます:: bugzilla_squid_url = http://www.squid-cache.org/bugs 上記の例はSquidのバグ 1234が修正されたものとしてマークするために ``bzr commit --fixes squid:1234`` を許可します。 trac__url ------------------------------ 存在するのであれば、Tracインスタンスの位置はによって参照されます。そのコミットによってバグが修正されたものとしてそのトラッカーの中でマークするためにこのオプションは ``bzr commit --fixes`` と一緒に使用できます:: trac_twisted_url = http://www.twistedmatrix.com/trac 上記の例はTwistedのバグ1234を修正したものとしてマークするために ``bzr commit --fixes twisted:1234`` を許可します。 bugtracker__url ------------------------------------ 存在するのであれば、一般的なバグトラッカーのインスタンスの位置はによって参照されます。位置は ``{id}`` プレースホルダーを含まなければなりません。プレースホルダーは特定のバグIDに置き換えられます。そのコミットによってバグが修正されたものとしてそのトラッカーでマークするためにこのオプションを ``bzr commit --fixes`` と一緒に使用できます:: bugtracker_python_url = http://bugs.python.org/issue{id} 上記の例はPythonのRoundupバグトラッカーのバグ1234を修正されたものとしてマークするために ``bzr commit --fixes python:1234`` を許可します:: bugtracker_cpan_url = http://rt.cpan.org/Public/Bug/Display.html?id={id} 上記はCPANのRTバグトラッカー用です。 .. _configuration-settings: 構成設定 ========= .. TODO: Should have some explanation of why you'd want things in .. branch.conf. 環境変数の設定 --------------- 大抵の設定が設定ファイルによって取り扱われる一方で、半永久的ないくつかのオプションは環境変数を通して制御できます。 BZR_EMAIL ~~~~~~~~~ Bazaarによって使用されるEメールのIDを上書きする。よくあるフォーマット:: "John Doe " ``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\\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 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 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 [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 editor ~~~~~~ コミットメッセージなしで *bzr commit* が実行された場合に使用されるエディタのパスです。この設定は環境変数 ``BZR_EDITOR`` によって設定され、環境変数 ``VISUAL`` と ``EDITOR`` によって上書きされます。 check_signatures ~~~~~~~~~~~~~~~~ 署名用のふるまいを定義します。 require リビジョン用のgnupg署名が存在して有効でなければなりません。 ignore リビジョンのgnupgの署名をチェックしない。 check-available (デフォルト) リビジョン用のgnupgの署名が存在する場合、それらをチェックします。わるい署名であることが分かるとBazaarは失敗しますが、署名が存在しない場合は失敗しません。 create_signatures ~~~~~~~~~~~~~~~~~ リビジョン署名のふるまいを定義します。 always コミットされるすべての新しいリビジョンに署名する。 when-required (デフォルト) ブランチが署名つきのリビジョンを要求するときのみ新しくコミットされたリビジョンに署名する。 never ブランチが署名を要求する場合でも新しくコミットされたリビジョンに署名するのを拒否する。 recurse ~~~~~~~ ``locations.conf`` でのみ便利です。このセクション用の設定をサブディレクトリにも適用するかどうか定義します: true (デフォルトこのセクションはサブディレクトリにも適用される。 false このセクションはこのディレクトリのブランチのみに適用されその下のブランチには適用されない。 gpg_signing_command ~~~~~~~~~~~~~~~~~~~ (デフォルト: "gpg"). リビジョンの署名とチェックのために使用されるプログラム。例です:: gpg_signing_command = /usr/bin/gnpg bzr_remote_path ~~~~~~~~~~~~~~~ (デフォルト: "bzr"). bzr用のスマートサーバーを稼働させるために使われるコマンドへのパス。この値はlocations.confでのみ指定が許可されます。理由は次のとおりです: - branch.confがアクセスできる前に必要だから - セキュリティリスクになるコマンドを指定するためにリモートのbranch.confファイルを許可するからこれはBZR_REMOTE_PATH 環境変数によって上書きされます。 smtp_server ~~~~~~~~~~~ (デフォルト: "localhost")。たとえば ``merge-directive --mail-to`` 、もしくはbzr-emailプラグインによって BazaarがEメールを送信する必要があるときに使用するSMTPサーバー、 smtp_username, smtp_password ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SMTPサーバーで認証するユーザーとパスワード。 smtp_usernameが設定されていて、smtp_passwordが設定されていなければ、Bazaarはパスワードを催促します。 Eメールを送信するためにSMTPサーバーが認証を必要とする場合のみこれらの設定が必要です。 mail_client ~~~~~~~~~~~ マージリクエストを送信するために使うメールクライアント。デフォルトでは、Windowsではbzrは ``mapi`` を使うことを試みます。他のプラットフォームでは、 ``xdg-email`` を試みます。これらのどちらかが失敗すると、 ``editor`` に戻ります。特定のクライアント用のサポートされた値: :claws: Clawsを使用する。ファイル添付のダイアログはスキップする。 :evolution: Evolutionを使用する :kmail: KMailを使用する :mutt: Muttを使用する :thunderbird: Mozilla ThunderbirdもしくはIcedoveを使用する。Thunderbird/Icedove 1.5に関して、これはxdg-emailが扱えないいくつかのバグに対処します。サポートされる一般的な値は次のとおりです: :default: 上記を参照。 :editor: マージリクエストを書くエディタを使用します。これはコミットID( ``bzr whoami`` を参照), smtp_serverと(オプションで)smtp_usernameとsmtp_passwordも使用します。 :mapi: Windowsで好きなメールクライアントを使用します。 :xdg-email: 好きなメールプラグラムを実行するためにxdg-emailを使用する submit_branch ~~~~~~~~~~~~~ 現在の作業内容を投稿しようとしているブランチ。これは ``bzr send`` によって自動的に設定され ``submit:`` リビジョンスペックにも使用されます。通常、これはブランチ単位ロケーション単位で設定されます。 public_branch ~~~~~~~~~~~~~ このブランチの公開されアクセス可能なバージョン (このブランチが公開されてアクセス可能ではないことを暗示する)。 ``bzr send`` によって使用されます(そして設定されます)。ブランチ特有のオプション ------------------------- これらのオプションは ``dirstate-tags`` もしくは後のフォーマットを使用するブランチにのみ適用します。通常これらは自動的に ``.bzr/branch/branch.conf`` 設定されるもしくは手動で ``locations.conf`` もしくは ``bazaar.conf`` に設定されます。 append_revisions_only ~~~~~~~~~~~~~~~~~~~~~ "True"に設定されていればリビジョンはログにのみ追加され、削除されません。この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。通常これは ``bzr init --append-revisions-only`` によって設定されます。 parent_location ~~~~~~~~~~~~~~~ 存在すれば、pullもしくはmerge用のデフォルトブランチの位置。通常このオプションは ``pull --remember`` もしくは ``merge --remember`` によって設定されます。 push_location ~~~~~~~~~~~~~ 存在すれば、push用のデフォルトブランチの位置。通常このオプションは ``push --remember`` によって設定されます。 bound_location ~~~~~~~~~~~~~~ チェックアウトとして振る舞うときコミットが向かう位置。通常このオプションは ``bind`` によって設定されます。 bound ~~~~~ "True"に設定されていると、ブランチはチェックアウトとしてふるまい、bound_locationにそれぞれのコミットをpushします。通常このオプションは ``bind``/``unbind`` に設定されます。衝突のタイプ ============= オペレーションの中には、merge、revertとpullのように、作業ツリーの内容を修正するものがあります。これらの修正はプログラムで生成されるので、作業ツリーの現在の状態と衝突することがあります。多くの種類の変更はプログラムで結合できますが、正しいことを行われているか時々人間だけしか判断できないことがあります。これが起きるとき Bazaarはあなたに衝突が存在するのでそれを解消するように伝えます。 Bazaarに衝突が解消したことを伝えるコマンドは ``resolve`` ですが、これを実行できる前にいくつかのアクションを実行しなければなりません。それぞれの衝突は下記のセクションで説明され、衝突を解消するために行わなければならないアクションの概要が説明されています。テキストの衝突 --------------- 典型的なメッセージは次のとおりです:: Text conflict in FILE テキストのマージが2つのセットのテキストの変更を完全に折り合いをつけられないときにこれらは生み出されます。 BazaarはTHIS、OTHER、とBASEのエクステンションでそれぞれのバージョン用にファイルをemitします。 THISはターゲットツリーからのファイルのバージョン、すなわち、変更をマージしようとしているツリーです。 OTHERはターゲットにマージしようとしているバージョン、BASEは比較用のベースとして使われる古いバージョンです。ファイルのメインコピーにおいて、Bazaarは調整できるすべての変更を含み、未調整の衝突は ``<<<<<<<`` のように "herringbone" マーカーによって囲まれます。たとえば、初期のテキストが "The project leader released it."、でTHISはこれを "Martin Pool released it." に修正する一方で、 OTHERは"The project leader released Bazaar."に修正します。衝突は次のようになります:: <<<<<<< TREE Martin Pool released it. ======= The project leader released Bazaar. >>>>>>> MERGE-SOURCE 正しい解消方法は"Martin Pool released Bazaar."になります。ファイルのメインコピーを編集する、もしくはTHIS、OTHERとBASEバージョン上で外部ツールを起動することのどちらかでテキストの衝突を扱うことができます。テキストの衝突の解消において他のものから変更のセットの1つの選別はめったにないことは言っておく価値があります。より頻繁に、2つのセットの変更はインテリジェントに結合しなければなりません。メインコピーを編集するとき、 herringbone マーカーを必ず削除してください。編集作業を終えたとき、ファイルは衝突がけっして起こらないようであれば、コミットする準備ができています。テキストの衝突を解消したとき、"bzr resolve"を実行するだけでBazaarは解消した衝突を自動検出します。内容の衝突 ---------- 典型的なメッセージ:: Contents conflict in FILE ターゲットツリーとマージソースの中の変更の衝突が存在するときにこの衝突は起こりますが、が衝突したアイテムはテキストファイルではありません。これらはバイナリファイルもしくはシンボリックリンクもしくはディレクトリになります。片方が削除され、もう一方が修正されたファイルでも起こり得ます。テキストの衝突のように、BazaarはTHIS、OTHER とBASEファイルをエミットしますが (これらは通常のファイル、シンボリックリンクもしくはディレクトリになります)、これはherringbone衝突マーカーを持つファイルの"メインコピー"を含みません。 "メインコピー"がTHISもくはOTHERにリネームされたときにこれは現れます。これを解消するには、ファイルを通常の名前に戻すために "bzr mv" を使用し変更を手動で結合します。満足したときに、 "bzr resolve FILE" を実行します。この種の衝突が解消されたときにBazaarは自動検出できません。重複したパス ------------- 典型的なメッセージ:: Conflict adding file FILE. Moved existing file to FILE.moved. 時々Bazaarはすでに使用されているパス名を用いてファイルを作成しようとします。既存のファイルは "FILE.moved" にリネームされます。望むのであれば、これらのファイルの1つをリネームするか、それらの内容を結合できます。満足したら、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行できます。バージョン管理下にない親 ------------------------- 典型的なメッセージ:: Conflict because FILE is not versioned, but has versioned children. ときどきBazaarは親ディレクトリがバージョン管理されていないファイルを作成しようとします。ターゲットの中でディレクトリが削除されたときにこれが起こりますが、ソースの中の新しい子を持ちます。逆も同様です。この状況において、Bazaarは親ディレクトリも同様にバージョン管理します。この問題の解決方法は特定のシナリオに大きく依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとして"bzr resolve FILE"を実行できます。見つからない親 --------------- 典型的なメッセージ:: Conflict adding files to FILE. Created directory. ターゲットの中でファイルを削除するときにこれが起こりますが、ソースの中に新しい子があります。これは "unversioned parent" の衝突と似ています。バージョン管理を解除される代わりに、親ディレクトリが *存在しない* ことを除いて、この状況において、Bazaarは見つからない親を作成します。この問題の解決方法は特定のシナリオに大いに依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとして "bzr resolve FILE" を実行できます。親を削除する ------------ 典型的なメッセージ:: Conflict: can't delete FILE because it is not empty. Not deleting. これは"見つからない親"の反対です。ソースの中でディレクトリは削除されますが、ターゲットの中で新しい子はあります。Bazaarはディレクトリを保有し続けます。この問題の解消は特定のシナリオに大いに依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとしてマークするために"bzr resolve FILE"を実行できます。パスの衝突 ----------- 典型的なメッセージ:: Path conflict: PATH1 / PATH2 ソースとターゲットがファイルの名前もしくは親ディレクトリを修正したときに起こります。 Bazaarはソースからパス要素を使用します。ファイルをリネームできれば、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。親のループ ----------- 典型的なメッセージ:: Conflict moving FILE into DIRECTORY. Cancelled move. ソースとターゲットがそれぞれディレクトリを移動させたので、変更が適用可能であれば、ディレクトリはそれ自身を含むときにこれは起こります。例です:: $ bzr init $ bzr mkdir a $ bzr mkdir b $ bzr commit -m "BASE" $ bzr branch . ../other $ bzr mv a b $ bzr commit -m "THIS" $ bzr mv ../other/b ../other/a $ bzr commit ../other -m "OTHER" $ bzr merge ../other この状況において、Bazaarは移動をキャンセルして、"a"を"b"の中に残しておきます。望むのであればディレクトリをリネームできれば衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。ディレクトリではない親 ----------------------- 典型的なメッセージ:: Conflict: FILE.new is not a directory, but has files in it. Created directory. 片方がファイルをディレクトリを追加したとき、もう一方がディレクトリをファイルもしくはシンボリックリンクに変更したときにこれは起きます。例です:: $ bzr init $ bzr mkdir a $ bzr commit -m "BASE" $ bzr branch . ../other $ rmdir a $ touch a $ bzr commit -m "THIS" $ bzr mkdir ../other/a/b $ bzr commit ../other -m "OTHER" $ bzr merge ../other MalformedTransform ------------------- Bazaarに例外のMalformedTransformを起動させること可能です(非常にまれですが)。これはBazaarが解決できないファイルシステムの衝突に遭遇したことを意味します。通常これはバグを示します。これに遭遇したら教えて頂くようお願いします。バグトラッカーは https://launchpad.net/bzr/+bugs です。現在のストレージフォーマット ============================ :pack-0.92: (ネイティブ) (デフォルト) 0.92で新しく導入: dirstate-tagsフォーマットリポジトリと互換性のあるデータを持つパックベースのフォーマット。 0.92以前のbzrリポジトリと相互運用できますが0.92以前のbzrでは読めません。以前はknitpack-experimentalと呼ばれていました。詳細な情報に関しては、 http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。 :1.6: (ネイティブ) スタックをサポートするディレクトリに基づいたブランチとパック。 :1.6.1-rich-root: (ネイティブ) スタックとリッチrootデータをサポートするブランチとパックベースのリポジトリ(bzr-svnが必要) :1.9: (ネイティブ) btreeインデックスを使用するブランチとパックベースのリポジトリ。 :1.9-rich-root: (ネイティブ) btreeインデックスとrich rootデータを使用するブランチとパックベースのリポジトリ(bzr-svnに必要)。ストレージフォーマットは ``bzr help formats`` を参照。環境変数 ======== ================ ================================================================= BZRPATH bzrがシェルプラグインコマンドを探すパス。 BZR_EMAIL ユーザーのEメールアドレス。EMAILを上書きする。 EMAIL ユーザーのEメールアドレス。 BZR_EDITOR コミットメッセージの編集用エディタ。EDITORを上書きする。 EDITOR コミットメッセージの編集用エディタ BZR_PLUGIN_PATH bzrがプラグインを探すパス。 BZR_HOME .bazaarの設定ディレクトリを保持するディレクトリ。HOMEを上書きする。 BZR_HOME (Win32) bazaar設定ディレクトリを保持するディレクトリ。APPDATAとHOMEを上書きする。 BZR_REMOTE_PATH リモート'bzr'コマンドのフルネーム(bzr+ssh:// URL用). BZR_SSH SSHクライアント: paramiko (デフォルト), openssh, ssh, plink. BZR_LOG .bzr.logの位置(ロギングを停止するには'/dev/null'を使う)。 BZR_LOG (Win32) .bzr.logの位置(ロギングを停止するには'NUL'を使う)。 ================ ================================================================= ファイル ======== :On Linux: ~/.bazaar/bazaar.conf :On Windows: C:\\Documents and Settings\\username\\Application Data\\bazaar\\2.0\\bazaar.conf ユーザーのデフォルト設定は上記のとおりです。 ``[DEFAULT]`` セクションすべての場所に適用される一般的な設定を定義するために使用できます。 ``[ALIASES]`` セクションは共通に使用されるオプション用のコマンドエイリアスを作成するために使用できます。典型的な設定ファイルは次のとおりです:: [DEFAULT] email=John Doe [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", ...) 例に関してはユーザーガイドの `フックを利用する`_ を参照してください。 .. _フックを利用する: ../user-guide/index.html#id186 それぞれのフックが含むクラスは下記のそれぞれのフックタイプの後で丸かっこの中で示されます。それぞれの説明ではクライアント(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 カラムの意味は次のとおりです。カラム 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を提供する)。 .. _authentication: `認証の設定`_ .. _bugs: `バグトラッカーの設定`_ .. _configuration: `構成設定`_ .. _conflicts: `衝突のタイプ`_ .. _current-formats: `現在のストレージフォーマット`_ .. _env-variables: `環境変数`_ .. _global-options: `グローバルオプション`_ .. _other-formats: `その他のストレージフォーマット`_ .. _revisionspec: `リビジョンの識別子`_ .. _standard-options: `標準オプション`_ .. _status-flags: `ステータスフラグ`_ .. _urlspec: `URLの識別子`_ コマンド ######### 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 "です。コミットされるツリーが無効である場合選択されたファイルのコミットが失敗することがあります。次の一連のコマンドを考えてみましょう:: 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 "