Bazaarのメインドキュメント¶

これらのドキュメントの最新版はBazaarのドキュメントのサイト、 http://doc.bazaar.canonical.com/en/ から入手可能で、詳しい情報は http://wiki.bazaar.canonical.com/Documentation のページからリンクされています。

目次¶

チュートリアル¶

5分でわかるBazaar¶

イントロダクション¶

Bazaarは分散型バージョン管理システムで、ソフトウェアプロジェクトの共同作業を楽にしてくれます。

これから5分ほどで、ファイルをバージョン管理下に置き、変更を記録して、作業内容を確認し、公開して作業内容をマージしてもらうためにプロジェクトの trunk に送る方法などを学びます。

詳細な紹介内容を望むのであれば、さらに学ぶをご覧ください。

インストール方法¶

このガイドではBazaarをインストールする方法を説明しませんが、通常はとても簡単です。インストール方法の手引きは次の通りです:

GNU/Linux: おそらくBazaarはあなたのGNU/Linuxディストリビューションに含まれています。
Windows: Windowsのためのインストールの手引き.
Mac OS X: Mac OS Xのためのインストールの手引き.

別のプラットフォームとソースコードからインストールする方法に関しては、ダウンロードとインストール方法のページを参照してください。

まずは自己紹介¶

作業にとりかかる前に、まずあなたが誰なのかをBazaarに教えてあげましょう。そうすることで、履歴の中からあなたの作業を正確に識別することができます。

次のように入力してください(もちろん、あなたの名前とEメールアドレスで):

$ bzr whoami "John Doe <john.doe@gmail.com>"

こうするとBazaarは、あなたの名前やEメールアドレスが入った設定ファイルを作成もしくは修正します。

名前とEメールアドレスが正しく登録されているか確認しましょう

$ bzr whoami
John Doe <john.doe@gmail.com>

ファイルをバージョン管理する¶

Bazaarで扱うディレクトリといくつかのファイルを作りましょう:

$ mkdir myproject
$ cd myproject
$ mkdir subdirectory
$ touch test1.txt test2.txt test3.txt subdirectory/test4.txt

Windowsユーザーのための注意: Windows Explorerを使ってディレクトリを作成し、そのディレクトリの中で右クリックをして 新規作成 を選択し、ファイルを作成します。

Bazaarにあなたのプロジェクトディレクトリを初期化させましょう:

$ bzr init

何も起きていないように見えても心配しないでください。 Bazaarはファイルとリビジョンの履歴を保存する branch を作りました。

次のステップはBazaarに管理して欲しいファイルを教えることです。 bzr add を実行するとすべてのディレクトリとファイルがプロジェクトに再帰的に追加されます。

$ bzr add
added subdirectory
added test1.txt
added test2.txt
added test3.txt
added subdirectory/test4.txt

次に、これらをブランチにコミットしてスナップショットをとります。コミットを行った理由を説明するメッセージを追加します。

$ bzr commit -m "Initial import"

Bazaarは分散型バージョン管理システムなので、コミットするためにサーバーに接続する必要はありません。代わりに、Bazaarはブランチとすべてのコミットをあなたが作業しているディレクトリ内部に .bzr というサブディレクトリを作ってそこに保存します。

ファイルを変更する¶

ファイルを変更してブランチにその変更をコミットしてみましょう。

好きなエディタで test1.txt を編集し、何を行ったのかを確認します。

$ bzr diff
=== modified file 'test1.txt'
--- test1.txt   2007-10-08 17:56:14 +0000
+++ test1.txt   2007-10-08 17:46:22 +0000
@@ -0,0 +1,1 @@
+test test test

作業をBazaarのブランチにコミットします:

$ bzr commit -m "Added first line of text"
Committed revision 2.

リビジョンのログを眺める¶

ログを閲覧することでブランチの履歴を調べることができます。

$ bzr log
------------------------------------------------------------
revno: 2
committer: John Doe <john.doe@gmail.com>
branch nick: myproject
timestamp: Mon 2007-10-08 17:56:14 +0000
message:
  Added first line of text
------------------------------------------------------------
revno: 1
committer: John Doe <john.doe@gmail.com>
branch nick: myproject
timestamp: Mon 2006-10-08 17:46:22 +0000
message:
  Initial import

ブランチを Launchpad で公開する¶

Launchpad はソフトウェアプロジェクトの開発と運営のためのツールをまとめたサイトです。自分のブランチを公開するために Launchpad を利用することができます。 (もちろん、自分のサーバーや他のホスティングサービス上で公開することもできます)

まだ Launchpad のアカウントを持っていないのであれば、 account signup guide に従ってアカウントを作成し、 SSH 鍵を登録してください。

次のように、 (john.doe は自分のアカウントのユーザー名に置き換えて) タイプしてください。 [1]

$ bzr push lp:~john.doe/+junk/myproject

[1]	`lp:` という URL スキーマは bzr 0.92 以降でサポートされています。

注意: +junk の部分は、このブランチが Launchpad 上の特定のプロジェクトに属していないことを意味しています。

これで、誰でもあなたのブランチのコピーを、次のようなコマンドで入手できるようになりました。

$ bzr branch lp:~john.doe/+junk/myproject

ブランチの情報を、履歴も含めて https://code.launchpad.net/people/+me/+junk/myproject から閲覧することができます。

別のブランチから自分用のコピーを作る¶

他人のコードに取り組むために、ブランチのコピーを作ることができます。実際の世界の例として、BazaarのGTKインターフェイスを見てみましょう:

$ bzr branch lp:~bzr/bzr-gtk/trunk bzr-gtk.john
Branched 292 revision(s).

Bazaarはbzr-gtkのtrunkブランチからすべてのファイルをダウンロードしてリビジョンの履歴をそろえ、bzr-gtk.johnというコピーを作ります。

これで、ブランチのコピーを手に入れたのでネットの接続のあるなしに関わらず変更をコミットできます。ブランチはいつでも公開することで共有でき、bzr-gtkチームがあなたの作品を使いたいと思ったときにBazaarは彼らがあなたのブランチから彼らのブランチにマージし直す作業を簡単にしてくれます。

メインのブランチから自分のブランチを更新する¶

変更を自分のブランチにコミットしている間に、他の人がコードを元のブランチにコミットしているということもよくあります。

自分のブランチを最新に維持するには、親ブランチから自分のブランチへと変更をマージします:

$ bzr merge
Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
All changes applied successfully.

何が変更されたのか確認します:

$ bzr diff

変更に満足したら、それらを自分のブランチにコミットします:

$ bzr commit -m "Merge from main branch"
Committed revision 295.

作業を親のブランチにマージする¶

bzr-gtkの個人ブランチに取り組んだ後で、あなたの変更を上流のプロジェクトに戻したいことがあるかもしれません。最も簡単な方法はマージディレクティブを使うことです。

マージディレクティブ(merge directive)とは、コンピュータに特定のマージを実行させるためのリクエストです。マージディレクティブは大抵、マージをレビューするためのパッチと、マージを実行するのに必要となるリビジョン、もしくはリビジョンを取得できるブランチを含みます。

次のコマンドの mycode.patch を適当な名前に書き換えて、マージのディレクティブを作ります:

$ bzr send -o mycode.patch
Using saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk

これでbzr-gtkのプロジェクトにマージディレクティブをEメールで送ることが可能になりました。彼らが納得すれば、親ブランチにマージすることができます。

さらに学ぶ¶

Bazaarに関する詳細な内容は Bazaarのユーザーガイドで調べることができます。

コマンドラインでBazaarを学ぶには:

$ bzr help

Bazaarのコマンドを学ぶには:

$ bzr help commands

‘’foo’’ トピックもしくはコマンドを学ぶには:

$ bzr help foo

Licence¶

Copyright 2007-2011 Canonical Ltd. Bazaar is free software, and you may use, modify and redistribute both Bazaar and this document under the terms of the GNU General Public License version 2 or later. See <http://www.gnu.org/licenses/>.

日本語訳について¶

この日本語訳は、 Bazaar-jaグループがメンテナンスしています。

日本語訳に着いて間違いや質問等ありましたらこちらへお願いします。

Bazaar チュートリアル¶

はじめに¶

もし、もう分散型バージョン管理に慣れ親しんでいるなら、 “Bazaarに自己紹介する” の節までとばしてください。もし、分散型でないバージョン管理に慣れ親しんでいるけれど分散型バージョン管理はよくわからないのであれば、”分散バージョン管理と分散でないバージョン管理の違い”までとばしてください。それ以外の場合、コーヒーか紅茶(訳注:日本茶でもいいですよ)を用意して、リラックスして読み始めてください。

バージョン管理の目的¶

なにかのテキストデータ(プログラムのソースコード、Webサイト、Unixシステムでの設定ファイルなど)を扱う作業をしているとしましょう。なにかミスをして、重大なデグレードを引き起こしてしまうかもしれません。例えばメールサーバーの設定ファイルを消してしまったり、だいじなプロジェクトのソースコードを壊してしまったりすることがあります。だいじな情報を失って、何が何でも取り戻したいと思った経験があるのであれば、きっとあなたはBazaarを使う準備ができています。

Bazaarをはじめとするバージョン管理システムは、ディレクトリに起こった変更をブランチ (branch) というディレクトリよりも複雑なものの中に入れて管理します。ブランチは今ディレクトリの中に何が入っているかだけでなく、過去のいろいろな時点でのディレクトリの中身を格納しています。なので、望まぬ変更をしてしまったときには過去の時点の状態に戻すことができます。

バージョン管理システムは、ユーザーが “リビジョン (revision) をコミット” することで変更をブランチに保存します。このときに生成されるリビジョンとは、本質的にいって、前回保存したときからの変更点になります。

リビジョンはそれ以外のものも持っています(原文:These revisions have other uses as well.) たとえば、オプションのログメッセージをつけることで、変更が何を意味しているのかというコメントを残すことができます。実際に利用されるログメッセージは、 “Webテンプレートをテーブルを閉じるように修正” とか “SFTPに対応した。 #595 を修正。” といったものです。

こういったログが保存されているおかげで、たとえば後になって SFTP に問題が発生したときに、問題が発生するようになったのがどの時点なのか目星をつけることができます。

分散バージョン管理と分散でないバージョン管理の違い¶

多くのバージョン管理システムはサーバーに配置されています。バージョン管理されているコードに対して作業をしたい場合、サーバーに接続してコードを “チェックアウト (checkout)” する必要があります。そうすると、変更やコミットができるディレクトリができます。バージョン管理システムのクライアントは、バージョン管理システムのサーバーにコミットされた変更を保存します。この方式は集中型として知られています。

集中型にはいくつかの欠点があります。集中型バージョン管理システムは、動作するためにサーバーとの接続を要求します。このことは、サーバーがどこかインターネット上にあって、あなたのマシンがインターネットに接続できないときに問題になります。もしくは、あなたのマシンがインターネットに接続できてもサーバーが落ちているときにもやはり問題になります。

分散バージョン管理システムは、ブランチをクライアントと同じマシンに置くことでこの問題を解決しています。 Bazaarの場合、ブランチはバージョン管理されているコードと同じディレクトリに保存されます。これにより、ユーザーは(たとえオフラインであったとしても)好きなときに変更を保存(コミット (commit))することができます。インターネット接続が必要になるのは、どこか別の場所にあるブランチの変更にアクセスするときだけです。

多くの人が必要としていることは、ディレクトリ内でおこったファイルやサブディレクトリの変更を追跡することです。この追跡を手でおこなうのは面倒で不恰好な作業です。これは、Bazaarのようなバージョン管理システムの目的のひとつです。バージョン管理システムはユーザーが指示したときにディレクトリツリーの リビジョン (revision) を作ることでこの作業を自動化します。

バージョン管理システムは単に保存したりundoしたりするだけではありません。たとえばBazaarでは、ソフトウェアのあるブランチから変更を取り出して、関連する別のブランチに適用することができます。このとき、変更を取り出すブランチは別の人のものであってもかまいません。これにより、開発者のグループはお互いに書き込み権を与えることなく共同作業することができます。

Bazaarではリビジョンの ‘’親 (ancestry)’’ 、つまりそのリビジョンの元になったリビジョンを記録しています。ひとつのリビジョンは複数の、それぞれ別の変更を含む子供リビジョンを持つことがあり、それはツリーの進化が分岐していることを意味しています。 Bazaarではブランチを作ることによって、複数の人が厳しい lock-step をとらなくても協力することができます。ブランチを作ることは個人での開発でも便利です。

Bazaarに自己紹介する¶

Bazaarは bzr という新しいコマンドをひとつインストールします。他の全ては bzr のサブコマンドになります。 bzr help コマンドでいくつかのヘルプを見られます。幾つかの話題は topic にまとめられていて、 bzr help topics で利用可能なトピックの一覧を見られます。

バージョン管理システムの一つの機能は、誰が何を変更したのかを追跡することです。分散型バージョン管理システムでは、各開発者がグローバルユニークなIDを持つ必要があります。ほとんどの人はこのIDとして利用できる eメールアドレスを持っています。 Bazaarはコンピュータのユーザー名とホスト名から自動でメールアドレスを生成します。Bazaarが自動で作成したメールアドレス以外のものを使いたい場合、３つの選択肢があります。

bzr whoami を使ってメールアドレスを設定します。これはグローバルなIDを設定する最も簡単な方法です。グローバルなIDを設定するには:
```
% bzr whoami "Your Name <email@example.com>"
```
特定のブランチでべつのアドレスを使いたい場合、そのブランチのディレクトリのなかで次のコマンドを実行します:
```
% bzr whoami --branch "Your Name <email@example.com>"
```
?/.bazaar/bazaar.conf [1] の中のメールアドレスを、以下のようにして設定します。 [DEFAULT] の部分が大文字と小文字を区別するので注意してください:
```
[DEFAULT]
email=Your Name <email@isp.com>
```
特定のブランチにおける設定は、 ?/.bazaar/locations.conf にブランチのセクションを作成して次のように書くことができます。
```
[/the/path/to/the/branch]
email=Your Name <email@isp.com>
```
環境変数 $BZR_EMAIL もしくは $EMAIL ($BZR_EMAIL の方が優先されます)にメールアドレスを設定することで、上の二つの方法で設定されたオプションを上書きすることができます。

[1]	Windowsではユーザー設定ファイルはアプリケーションデータディレクトリにおかれます。なので、設定ファイルの場所は `?/.bazaar/branch.conf` ではなく`C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf` になります。同じことが `locations.conf`, `ignore`, `plugins` ディレクトリも同じです。

ブランチを作る¶

履歴はデフォルトではブランチの .bzr ディレクトリの中に保存されます。

既存のディレクトリの中で bzr init をすると新しいブランチを作成できます:

% mkdir tutorial
% cd tutorial
% ls -a
./  ../
% pwd
/home/mbp/work/bzr.test/tutorial
%
% bzr init
% ls -aF
./  ../  .bzr/
%

ファイルには３つのクラス、 unknown, ignored, versioned があります。 add コマンドはファイルを versioned にし、そのファイルへの変更の記録を開始します:

% echo 'hello world' > hello.txt
% bzr status
unknown:
  hello.txt
% bzr add hello.txt
added hello.txt
% bzr status
added:
  hello.txt

もし間違えたファイルを add してしまった場合、そのファイルを unversioned 状態に戻すために bzr remove してください。この場合の bzr remove は、ほかの場合 [2] とちがってファイルを削除しません。

[2]	(1, 2) `bzr remove` はファイルがバージョン管理されていて何も変更されていない場合に、そのファイルを削除します。 `--keep` オプションで常にファイルを残すことができます。 `--force` オプションで常にファイルを削除することもできます。

ブランチの場所¶

すべての履歴はブランチに格納されます。ブランチとは、管理用のファイルを含んだただのディレクトリです。デフォルトでは、svnやsvkのような、分離したリポジトリやデータベースはありません。分離したリポジトリを作成することもできます(bzr init-repo コマンドを参照してください)。大規模なブランチを利用する場合や、中規模のブランチをたくさん利用する場合にはリポジトリを分離するといいでしょう。

自分のコンピュータのファイルシステム上にあるブランチを参照するときはブランチを格納しているディレクトリ名で指定できます。 bzr は SSH, HTTP SFTP などを経由してブランチにアクセスすることもできます。例:

% bzr log bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
% bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
% bzr log sftp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/

プラグインをインストールすれば、 rsync プロトコルを使ってブランチにアクセスすることもできます。

ブランチを指定した場所に置く方法については、ブランチを公開する節をご覧ください。

変更をレビューする¶

一仕事終えたら、それを履歴に コミット (commit) しましょう。新しい機能を追加したり、バグを直したり、コードやドキュメントを更新したらいつでもコミットするのは良いことです。すべてのリビジョンが良い状態であるようにするために、コミットする前にコードをコンパイルしたりテストスイートを実行するのも良い習慣です。コミットする前にコミットしようとしているものを確認するためにレビューすることができます。

この目的で便利な二つのコマンドがあります。 status と diff です。

bzr status¶

status コマンドは、今の作業ツリーが最後のリビジョンからどのように変更されたのかを教えてくれます:

% bzr status
modified:
   foo

bzr status は変更が無かったり無視されているファイルを隠します。 status コマンドはオプションとして、確認対象となる複数のファイル名やディレクトリ名を渡すことができます。

bzr diff¶

diff コマンドは通常の unified diff フォーマットですべてのファイルのテキストの変更を表示します。このコマンドの出力を pipe 経由で、’‘patch’‘, ‘’diffstat’‘, ‘’fileterdiff’‘, ‘’colordiff’’ といったコマンドに渡すことができます。

% bzr diff
=== added file 'hello.txt'
--- hello.txt   1970-01-01 00:00:00 +0000
+++ hello.txt   2005-10-18 14:23:29 +0000
@@ -0,0 +1,1 @@
+hello world

-r オプションをつけると、作業ツリーを古いリビジョンと比較したり、二つのリビジョン間の差分を見ることができます。

% bzr diff -r 1000..          # everything since r1000
% bzr diff -r 1000..1100      # changes from 1000 to 1100

--diff-options オプションをつけると、 bzr は外部の diff プログラムにオプションをつけて起動します。例:

% bzr diff --diff-options --side-by-side foo

プロジェクトによっては二つのファイルに接頭辞がついた patch が好まれます。 --prefix オプションでそのような接頭辞をつけることができます。ショートカットとして、 bzr diff -p1 は patch -p1 コマンドが受け付ける形で差分を出力します。

変更をコミットする¶

作業ツリーの状態に満足したら、ブランチに コミット (commit) しましょう。コミットとは作業ツリーの状態のスナップショットを保持するリビジョンを新しく作ることです。

bzr commit¶

commit コマンドはそのリビジョンの変更を説明するメッセージを受け取ります。また、あなたのユーザーID、今の時間とタイムゾーン、ツリーの内容をあわせて記録します。コミットメッセージは -m もしくは --message オプションで指定できます。複数行のコメントも利用できます。多くのシェルはクォートを開いたままで改行することで複数行の入力が可能です。

% bzr commit -m "added my first file"

メッセージをファイルで渡すには -F オプションを使います。コミットメッセージを先に作成し、それとdiffを合わせてレビューすることで、コミットメッセージとコミット内容が一致していることを確認する人もいます。 (このファイルは休憩から戻ってきて作業を思い出すときにも役に立つでしょう)

エディタからメッセージを入力する¶

-m オプションも -F オプションも指定しなかった場合、 bzr はメッセージを入力するためにエディタを立ち上げます。このエディタは $VISUAL か $EDITOR 環境変数で制御することができます。この環境変数を `` /.bazaar/bazaar.conf`` 内の editor を設定して上書きすることができ、さらに $BZR_EDITOR 環境変数がそれらすべてを上書きします。もし何も変更せずにエディタを閉じたなら、コミットはキャンセルされます。

エディタで開かれるファイルには水平線が含まれています。この線より下の部分は参考用であり、コミットメッセージには含まれません。水平線の下にはコミットで変更されるファイルのリストが表示されます。メッセージは水平線の上に書く必要があります。そうしたら、ファイルを保存してエディタを終了してください。

commit コマンドに --show-diff オプションをつけると、コミットされる変更の diff を見ることができます。この diff はエディタが開いたときに水平線やコミットされるファイルの情報よりも下に含まれます。なので、コミットメッセージを書くときに diff を見ることができますが、コミットメッセージ自体には diff が含まれません。コミットメッセージに diff を含めたい場合は、水平線より上にコピーペーストしてください。

解決したバグの記録をつける¶

プロジェクトにおいて多くの変更はバグの修正のために行われます。 Bazaar は、コミットするときに解決したバグについてメタデータに記録することができます。これを行うには、 --fixes オプションを使います。このオプションは次のような形の引数を取ります。

% bzr commit –fixes <tracker>:<id>

<tracker> の部分にはバグ管理システムを指定するIDを書き、 <id> の部分にはそのバグ管理システム上で管理されているバグの IDを書きます。 <id> はたいてい数値になるでしょう。 Bazaar は最初からいくつかの有名なバグ管理システムを知っています。 bugs.launchpad.net, bugs.debian.org bugzilla.gnome.org です。これらは、それぞれ独自のIDとして lp, deb, gnome を持っています。例えば、 bugs.launchpad.net 上のバグ #1234 を解決する場合は、その解決をコミットするときに次のようなコマンドを利用できます。

% bzr commit -m "fixed my first bug" --fixes lp:1234

For more information on this topic or for information on how to configure other bug trackers please read Bug Tracker Settings.

このトピックに着いてのさらなる情報や、他のバグ管理システムを設定する方法については、 Bug Tracker Settings を参照してください。

選択コミット¶

commit コマンドにファイル名やディレクトリ名を渡したとき、それらのファイルの変更だけがコミットされます。例

% bzr commit -m "documentation fix" commit.py

デフォルトでは bzr は、サブディレクトリから実行される場合でもすべての変更をコミットします。カレントディレクトリ以下だけをコミットする場合は、次のようにします

% bzr commit .

コミットされていない変更を削除する¶

不要な変更がある場合、 revert コマンドで最後のリビジョンの状態に戻ることができます。 revert するまえに bzr diff で何が削除されるのかを確認しておくと良いでしょう。デフォルトでは revert コマンドはツリー全体を revert します。ファイル名やディレクトリ名が指定されている場合は、そのファイルだけが revert されます。 bzr revert はマージ待ちリビジョンのリストも削除します。

ファイルを無視する¶

.bzrignore ファイル¶

多くのソースツリーはバージョン管理する必要のないファイルをたくさん含んでいます。たとえば、エディタのバックアップファイルや、オブジェクトファイル、バイトコード、ビルドされたプログラムなどです。こういったファイルを単に add しないこともできますが、そうすると毎回 unknown file としてたびたび出現することになります。ツリートップにある .bzrignore とよばれるファイルにそれらのファイルを追加することで、bzrにそれらのファイルを無視させることができます。

このファイルは行ごとにワイルドカード (もしくは”glob”) のリストを含みます。典型的な内容の例です:

*.o
*?
*.tmp
*.py[co]

glob がスラッシュを含む場合、ツリーのトップからのパス全体にマッチします。そうでない場合は、単にファイル名にマッチします。なので、上の例はすべてのサブディレクトリの .o 拡張子を持つファイルを無視しますが、次の例ではツリーのトップにある config.h ファイルと、 doc/ ディレクトリ以下のHTMLファイルだけを無視します:

./config.h
doc/*.html

どのファイルがどのパターンにマッチして無視されているのかを、 bzr ignored コマンドで表示することができます:

% bzr ignored
config.h                 ./config.h
configure.in?            *?

バージョン管理されているファイルが無視パターンにマッチしたり無視リストに入っていても大丈夫です。無視パターンはバージョン管理されたファイルには影響しません。バージョン管理されていないファイルを ‘unknown’ として扱うか’ignored’ として扱うかを決めるためだけに使われます。

.bzrignore ファイルは普通はバージョン管理されます。なのでそのブランチのコピーでも同じパターンが無視されます。

% bzr add .bzrignore
% bzr commit -m "Add ignore patterns"

bzr ignore¶

.bzrignore ファイルを直接編集する代わりに、 bzr ignore コマンドを利用することができます。 bzr ignore コマンドはファイル名かパターンを引数に受け取って、それを .bzrignore ファイルに追加します。 .bzrignore ファイルが存在しない場合、 bzr ignore コマンドは自動的にそのファイルを作成してバージョン管理に追加します。

% bzr ignore tags
% bzr status
added:
  .bzrignore

.bzrignore ファイルを自分で修正したときと同じく、コマンドを実行したあとに .bzrignore ファイルをコミットしなければなりません。

% bzr commit -m "Added tags to ignore file"

グローバルの無視設定¶

エディタの一時ファイルや個人の一時ファイルなど、幾つかの無視ファイルはプロジェクト依存ではなくてユーザー依存です。こういったファイルを全プロジェクトで無視設定するかわりに、グローバルの無視設定ファイル ~/.bazaar/ignore を利用できます。これはプロジェクトの ignore ファイルと同じ文法で記述します。

履歴を閲覧する¶

bzr log¶

bzr log コマンドは過去のリビジョンのリストを表示します。 bzr log --forward コマンドは同じ内容を、時系列順で最新のものが最後にくるように出力します。

bzr diff と同じように、 bzr log も -r 引数をサポートします:

% bzr log -r 1000..          # リビジョン r1000 とそれ以降すべて
% bzr log -r ..1000          # r1000 とそれ以前のすべて
% bzr log -r 1000..1100      # r1000 から r1100 まで
% bzr log -r 1000            # リビジョン r1000 だけ

ブランチの情報¶

bzr info コマンドは作業ツリーとブランチの履歴に関する情報の要約を表示します。

ディレクトリをバージョン管理する¶

bzr はファイルとディレクトリを、名前の変更を追跡して賢くマージできるようにバージョン管理します:

% mkdir src
% echo 'int main() {}' > src/simple.c
% bzr add src
added src
added src/simple.c
% bzr status
added:
  src/
  src/simple.c

ファイルを削除する¶

ファイルを削除するのは、単純に作業ツリーからファイルを削除するだけでできます。これは、 cvs remove が必要な CVS とは少し異なります。

bzr remove はファイルをバージョン管理対象からはずしますが、作業ツリーから削除することも削除しないこともできます。 [2] これは間違ったファイルを追加してしまったり、あるファイルをバージョン管理するのをやめる場合に便利です。

% rm -r src
% bzr remove -v hello.txt
?       hello.txt
% bzr status
removed:
  hello.txt
  src/
  src/simple.c
unknown:
  hello.txt

もし間違ってファイルを削除してしまった場合、 bzr revert でリストアできます。

ブランチを作る¶

自分でプロジェクトを始めるのではなく、既存のプロジェクトに変更を加えたい場合があります。この場合、既存のブランチのコピーを取得する必要があります。このコピーは新しいブランチになるので、このコマンドは branch という名前になっています:

% bzr branch lp:bzr bzr.dev
% cd bzr.dev

これでブランチの完全な履歴をコピーできたので、すべての操作 (log, annotate, branch の作成とマージなど) をローカルで実行できます。履歴の一部だけを取得するオプションも追加される予定です。

既存のブランチをコピーするには、普通にディレクトリをコピーしたり、tarballを展開したり、リモートから rsync のような方法でコピーすることもできます。

上流の変更を追いかける¶

変更を “pull” することで手元のブランチを上流のブランチに対して最新に保つことができます。

% bzr pull

このコマンドを実行した後、ローカルディレクトリはpull元のミラーになります。ミラーするものには、 ‘’revision-history’’ を含みます。つまり、別のブランチからマージするのではなくて、このブランチに対してコミットした履歴になります。

このコマンドはローカルの(pull先)ブランチが親ブランチの古いコピーで独自のあたらしいリビジョンを一切含まないか、ローカルブランチへの最新のコミットが親ブランチにマージされているときにのみ成功します。

ブランチを公開する¶

bzrのブランチを公開するには特別なサーバーは必要ありません、普通のWebサーバーが使えます。 .bzr ディレクトリを含めてファイルをサーバーにミラーしてください。ブランチをpush(やブランチに対する操作)するのに以下の3つの方法があります。

最良の方法は bzr 自体を使うことです。

% bzr push bzr+ssh://servername.com/path/to/directory

別の選択肢は bzrtools に含まれる rspush プラグインを利用することです。これはリモートの履歴と作業ツリーに変更を push するのに rsync を利用します。

tarball を送ったり rsync を使ったりほかの転送方法を利用して、手動でファイルをコピーすることもできます。これはたいてい push ほど安全ではありませんが、場合によって高速だったり、簡単だったりするかもしれません。

変更をツリー間で移動する¶

どんな人にでもありえることですが、適切ではないツリー上で変更してしまうことがあります。単純に作業するディレクトリを間違えたり、変更が予想よりも大きくなってしまったりして、その変更のために新しいブランチを作りなおすことがあります。

変更をあるツリーから別のツリーに移動するには

% cd NEWDIR
% bzr merge --uncommitted OLDDIR

これですべてのコミットされていないOLDDIR上の変更がNEWDIRに適用されます。コミットされていない変更は、通常のmergeでNEWDIRに適用することができる場合でも適用されません。 OLDDIR上の変更はそのまま残りますが、NEWDIRの状態に満足したら bzr revert OLDDIR で削除することができます。

NEWDIRはOLDDIRのコピーである必要はありませんが、関連しているべきです。両者の違いが大きければそれだけ衝突が起こる可能性が大きくなります。

LaunchpadでBazaarを使う¶

動機付け¶

コミュニティはチームとは違う¶

ソフトウェアの初回リリースをしなければならない人々のチームというのは、一人から数千人まで、その規模は多岐に渡ります。その要求に応じて、技術的な課題、経営上の課題、その両方が非常に大きなものになる可能性があります。 Bazaarユーザガイドで説明したように、”ふさわしい”プロセスを選択し、それに見合ったワークフローをサポートするBazaarのようなツールを使うことは、大きな手助けになるでしょう。

しかし、ソフトウェアによる成功のためには、すばらしいチーム以上のものが必要です。 - それは、健全で活発な コミュニティ です。このグループは、通常はチームよりもはるかに大きく、なぜならそのソフトウェアに関心のあるすべての人 - 開発チーム、ユーザ、トレーニングパートナー、サポートパートナー、サードパーティの開発者など - を含むからです。

すばらしいコミュニティというものはフリー(自由)ソフトウェアコミュニティでは良く理解されています。しかし、その適用はオープンソースの世界を越えて広がっています。もっとも成功している商業ソフトウェアのベンダーは、そのフラッグシッププロダクトと共に成長するコミュニティを作り上げ、運営することがたくみなのです。

すばらしいチームと同じように、すばらしいコミュニティも偶然できるものではありません。良いポリシーとガイドラインが、参加者同士の健全なコミュニケーションと正しい振る舞いを育てるために不可欠です。この話題についてもっと深く知りたければ、Karl Fogelのすばらしい著書 - Producing Open Source Software - を見てください。

協調開発に必要なもの¶

コミュニティの情報とワークフローを追跡し、管理するためには、賢いツールセットが重要です。そのようなツールを、協調開発環境(Collaborative Development Environments : CDEs)と呼びます。一般的には、WEBベースでアナウンスや案件、バグを管理します。 Launchpad 、 SourceForge 、 java.net 、 SAP Community Network などに、CDEsの例があります。

関係するコミュニティとの協調を助ける¶

多くの成功しているプロダクトは、その下流にそれを使うたくさんのプロダクトがあります。言いかえると、他のコミュニティとやりとりをして、自分の変更が彼らにどんな影響を与えるかを理解することで、新しい挑戦が成功するのです。これは、以下のようなプロダクトでは特に明白です。:

プログラム言語、たとえばPyhon、PHP、Ruby、Java、Perlなど
コンパイラ、たとえばgcc、JDKなど
ライブラリ、たとえばzlib、opensslなど
フレームワーク、たとえばZope、Ruby on Rails、Springなど

しかし、アドオン機能を持つメジャーなアプリケーション、たとえばFirefox、Thundervird、OpenOffice.org、Drupal、Wordpress、Joomlaなどにも、このことはあてはまります。

コミュニティの境界をこえて案件や障害修正の追跡と管理をするための作業をサポートしてくれるツールが必要です。そのようなツールは、両極端にいるどちらのユーザも助けてくれます。:

自分のことばで問題を報告することができるユーザ。たとえば、「オペレーションシステムX上のアプリケーションYで、Zタイプのイメージのレンダリングがおかしい」など
変更や障害修正が下流のプロダクトに与える影響をよりよく評価できる開発者。たとえば、「グラフィックライブラリのバグを修正することにより、これらの10個のOS上の5つのアプリケーションに恩恵がある」など

その間にいる人々は、 点線をつなぎ 、上流と下流との間のコミュニケーションを担うという重要な役割を果たします。多くの場合、彼らはエンドユーザのためにバグを修正したり、パッチをリリースしたり、上流の開発チームに修正内容を提示したりします。それらすべてを持続可能な方法で常に追跡しつづけることは、簡単なことではありません。

Launchpad: 開発をもっと効果的に、摩擦は少なく¶

Canonical は、 Ubuntu や Bazaar の開発に出資しているのと同じように、オープンソースコミュニティ向けの無料のサービスとして Launchpad <https:launchpad.net> も提供しています。 Launchpadは、以下の注目すべき理由から、もっともエキサイティングな CDEsのひとつです。

トラッキング対象のたくさんのもの同士の関係を具体化しています。たとえば、ソースコードのブランチをバグ修正に関連づけることができます。
これまでの資産を管理するのと同じように、ロードマップ、マイルストーン、ブループリントの機能によってこれからの開発の計画や追跡もできます。
翻訳ツールやパッケージングサービスを提供することで、翻訳者やテスターがコミュニティに参加し、貢献するときの抵抗を少なくしています。
違うコミュニティ同士が、関連する案件やロードマップに対してともに作業するための結びつきを提供します。

言いかえると、Launchpadは、あなたのコミュニティの成長を助け、 コミュニティ内 とコミュニティ間 との両方でワークフローの摩擦を減らすようにデザインされています。究極的には、機械的なタスクにつかう時間をなくし、興味ぶかい開発により多くの時間をさけるようにすることを意味しています。

Bazaar: Launchpadのバージョン管理クライアント¶

このチュートリアルは、BazaarとLaunchpadがどのようにして一緒に使うことができ、どれだけお互いを引き立てあうのかを考えます。以下のことは覚えておいてください。:

BazaarはLaunchpadなしで使うこともできます。
LaunchpadはBazaarなしで使うこともできます。

それでも、別々に使うよりも一緒に使った方がより大きな力を発揮するように設計されています。

Launchpadでのブランチの検索、閲覧¶

利用できるブランチの検索¶

分散型バージョン管理を導入することには多くの利点がありますが、できなくなってしまうことのひとつとして、利用できるすべてのブランチについて知っている中央サーバがないという点があります。実際、分散環境では、関連するブランチは、インターネット中の文字どおり100もの場所に存在する可能性があります。(もしくは、イントラネットの中でも同様です。)

Launchpadは、ブランチのデータベースを提供することによって、このギャップをなくします。

ブランチの登録¶

ブランチはLaunchPadにアップロードすることもできますし、別の場所にあるブランチを単に登録することもできます。また、ブランチには New(新規) 、 Development(開発バージョン) 、 Mature(安定) 、 Abandoned(破棄) というステータスを付加することができます。

Note: 外部のブランチは、CVSやSubversionのような従来のバージョン管理ツールでホストされていても構いません。これらのシステム上のコードは定期的にスキャンされ、Bazaarのブランチに変換されます。もちろん、最大限の正確さを求めるのであれば、外部のブランチをBazaarでホストすることが望ましいです。

ブランチの閲覧¶

ブランチは、名前、登録者、作者、ステータス、世代、最終コミット時刻などの多くの属性によってリストアップやフィルタリング、並べ替えができます。また、ブランチを閲覧することによって、以下のようなことが簡単に分かります。:

ブランチがどこからダウンロードできるか
変更をアップロードする方法
それぞれで行った最近のコミットと変更内容
指定したバージョンの個々のファイルのソースコード

Launchpad上のコードへのBazaarでのアクセス¶

プロジェクトのコードの取得¶

Launchpad 上には多数のプロジェクトがあり、その最新のコードがBazaarで管理されていても、CVSやSubversionで管理されていても、Bazaarを使って以下のように簡単にコードを取得することができます。

bzr branch lp:project-name

project-name は、Launchpad上のプロジェクトIDです。以下にいくつか例を挙げます。:

bzr branch lp:inkscape
bzr branch lp:amarok
bzr branch lp:python
bzr branch lp:rails
bzr branch lp:java-gnome

そのあと、好きなエディタやIDEを使って、コードを手元で参照したり、必要があれば編集したりすることができます。

もし、プロジェクトに複数のシリーズ(例えば、開発用とメンテナンス用)が登録されている場合は、以下のコマンドで指定したシリーズの最新のコードを取得することができます。:

bzr branch lp:project-name/series

変更内容の公開¶

イライラするバグを修正したり、ずっと欲しかったクールな機能を追加したりしたら、それを友達にアピールしたり、そのコードを他の人に公開して世の中をもっと良くするときです。これまでに説明したとおり、LaunchpadはBazaarによる無料のコードホスティングサービスなので、自分のブランチをプッシュして他の人がそこからコードにアクセスできるようにすることができます。例えば、あなたが関連するチームのメンバーだとすると、以下のようにLaunchpadにログインします。:

bzr launchpad-login userid

userid は、LaunchpadのユーザIDです。そのあと、以下のように変更をチームのブランチにプッシュすることができます。:

bzr push lp:~team-name/project-name/branch-name

他の人は、以下のようにそのコードをダウンロードすることができます。:

bzr branch lp:~team-name/project-name/branch-name

自分用のブランチ¶

あなたがチームのメンバーではなかったとしても、Launcpadであなたの変更内容を公開することができます。この場合、以下のようにして単純に自分用のブランチを作成します。:

bzr push lp:~userid/project-name/branch-name

他の人は、以下のようにそのコードをダウンロードすることができます。:

bzr branch lp:~userid/project-name/branch-name

Note: 自分用のブランチに公開したときも、ちゃんと上流の開発者にあなたのブランチについて通知されるので、全てのユーザに一般的に適用できる内容で、かつプロジェクトの品質基準を満たしていれば、彼らはその変更をプルすることができます。

パッケージのソースブランチ¶

maintaining packages for Ubuntu using Bazaar に書かれているとおり、 Launchpad から簡単にパッケージのソースブランチにアクセスできます。現在の(デフォルトの)系列のパッケージのソースブランチは、次のようなコマンドでダウンロードできます。

bzr branch ubuntu:package

ここで、 package はアクセスしたい Ubuntu のパッケージ名です。 Ubuntu の特定の系列 (例: Maverick, Lucid) のパッケージブランチをダウンロードするには、次のコマンドを使います。

bzr branch ubuntu:maverick/package

Ubuntu の系列は単に最初の文字を使う形に省略することができます。たとえば、上の例は次のようにも書けます。

bzr branch ubuntu:m/package

いくつかの Debian の系列でも、 Launchpad からソースブランチをダウンロードすることができます。デフォルトの系列であれば次のようにダウンロードできます。

bzr branch debianlp:package

そして、特定の系列の場合は次のようになります。

bzr branch debianlp:lenny/package

debianlp: スキーマは　Launchpad にある Debian のソースブランチにしかアクセスできないので注意してください。

Lanchpadでのブランチの関連づけ¶

ブランチをバグと関連付ける¶

ブランチを登録したあと、それにバグを関連づけることができます。そうすることで、そのバグに関心をもつ人々がそのブランチを追いかけ、修正が公開されたらダウンロードすることができます。

そのための手順は以下のとおりです。

Questionから、そのバグに移動します。
Actions から Add branch を選択します。
ブランチを選択します。
必要に応じて、関連づけのステータスを設定します。 Fix In Progress(修正中) がデフォルトですが、すでにブランチ内にで問題に対処しているのなら、Fix Available(修正済) に設定することもできます。

もし望むのなら、バグとブランチとの関連づけに好きなコメントをつけることもできます。

BazaarでのコミットによるLaunchpadのステータスの変化¶

BazzarとLaunchpadを一緒につかうことで、ステータスのメンテナンス作業をへらすことができます。 Bazaarでコミットしたときに、以下のように–fixesオプションを指定します。:

bzr commit --fixes lp:1234 -m "..."

この1234というのはバグIDです。こうすると、バグ-ブランチ間の関連づけのステータスが Fix Available に変わります。一回のコミットで複数の問題を修正する場合には、–fixesオプションを複数回指定できます。

この機能のすばらしい点のひとつは、コミットするときにLaunchpadにアクセスできなくてもいいということです。 --fixes オプションではメタデータを保存し、次にそのブランチがLaunchpadにプッシュされたときか、オンラインで再スキャンされたときに、Launchpadはそのメタデータを検出します。

Note: Launchpadは、ブランチでバグが修正されたからといって勝手にバグをクローズすることはありません。これにはいくつかの理由があります。一つ目の理由は、ほとんどのチームでは、たいていブランチをトランク(メインの開発ブランチ)にマージしないとバグが修正されたとはみなさないためです。二つ目の理由は、多くのチームでは、バグが修正されたことを確認するためには、「開発者がそう言っている」というだけではなくそれ以外のプロセスがあるためです。

あとで説明しますが、マージ管理機能が現在Launchpadで開発されており、この機能がリリースされれば、バグのステータスを Fix Committed に自動変更する機能がもっと適切なものになります。

ブランチをブループリントと関連づける¶

ブランチを登録したあと、それにブループリントを関連付けることができます。そうすることで、そのブループリントに関心を持つ人々がそのブランチを追いかけ、開発中の新機能をテストすることができます。

そのための手順は以下の通りです。

Questionから、そのブループリントに移動します。
Actions から Link branch を選択します。
ブランチを選択します。

もし望むのなら、ブループリントとブランチとの関連づけに好きなコメントをつけることもできます。

Launchpadをつかったリリースの管理¶

変更内容の統合¶

ブランチが開発され、公開されたら、コミュニティでは一般的に、その変更内容をコアプロダクトに統合してエンドユーザにリリースする前に厳格なプロセスを通します。その中には、以下のような手順が含まれるでしょう。:

仲間による変更内容のレビュー
どのリリースにその変更を含めるかの決定。たとえば、次のメンテナンスリリース、次のメジャーリリース、もしくはその両方。
機能の回帰テストの実行
パフォーマンスが基準を満たすかどうかを確認するためのベンチマーキング
エンドユーザテストのための早期提供リリースの作成
ドキュメントの更新。たとえば、そのリリースのためのリリースノートなど
ユーザインターフェイスやドキュメントの他言語への翻訳

このセクションでは、プロダクトのコードの品質を高めるために役立つLaunchpadの機能のいくつかについて簡単に説明します。 Bazaarとの強力な一体化が、それをスムーズにするためのポイントです。

Note: 以下にあげる機能の中には、まだ開発中のものもあります。もし、これらの機能に興味があるのなら、以下のリンクでLaunchpadベータテストチームへの参加を検討してください。: https://help.launchpad.net/JoiningLaunchpadBetaTesters そうすれば、各機能の早期提供版を手に入れて、広くリリースされる前に開発者にフィードバックを送ることができます。

ブランチのマージの提案¶

Launchpadでブランチに移動したあとに実行できるアクションのひとつに、 Propose for merging(マージの提案) があります。この機能では、どのブランチがこのコードを取り入れるべきかを指定します。

どのブランチがコードラインへのマージ提案中なのかという情報を追跡することは、リリース管理者が、リリース日までに何を完了させなければならないか、または何を完了させることができるかを常に把握するために役立ちます。この情報をもとに、必要なレビューを実行してからブランチをマージすることを確実に行うことができます。単純なケースでは、リリース管理者は手作業でブランチをマージします。もっと高度なケースでは、ブランチがあるべきステータス(たとえば、 Review completed(レビュー完了))になったときにロボット(PQM のような)に自動的にマージさせることができます。

コードレビューの追跡¶

コードレビューの状態や会話の内容、成果物を追跡するために、Launchpadでたくさんの機能が開発されています。これらの機能は、ブランチのマージ提案やブランチ閲覧の機能に統合されると思われます。

パーソナルパッケージアーカイブ(PPA)¶

PPAは、開発者や開発チームが、早期提供版でテストとフィードバックを行うユーザにカスタムビルドモジュールを渡す手助けをします。言い方を変えると、PPAによって、開発者はその変更内容に関心を持つテスターのコミュニティを結成することができるようになります。テスティングコミュニティは、パッケージをインストールし、テスト期間中にそれを実行し、その後はシステムからきれいに削除することができます。

より詳細な情報は、 https://help.launchpad.net/PPAQuickStart を参照してください。

翻訳¶

Launchpadの翻訳モジュールは、誰もがアプリケーションを自分が知る言語に簡単に翻訳できるように設計されています。翻訳者は、深いレベルの詳細を知る必要はありません。

Launchpadは、プロジェクトの各メジャーバージョンに対する翻訳を別々に記録するので、だれかが新しい開発バージョンの作業を始めていても、安定版の翻訳の改良を続けることができます。プロジェクトをまたがってリソースを共有することにより、翻訳のスピードを短縮しています。 75万件の翻訳済みのテキストのライブラリからの自動抽出機能と、1万9千人の翻訳者のコミュニティとが、プロジェクトを多くの言語に翻訳する時間を短縮してくれます。

要約¶

私たちが参加するコミュニティは、それがオフラインであれオンラインであれ、私たちがどのような種類の人間であるかを表すものです。逆に言うと、あなたがコミュニティのために選ぶツール - 特に、CDEとバージョン管理ツール - は、誰がそのコミュニティに参加するのかということ、また、その人たちがどれだけ簡単にコミュニティに貢献できるかということに大きな影響を与えます。

LaunchpadとBazaarは、単独でもとても役に立つツールです。一緒に使えば、以下のことが可能になります。:

コミュニティの、ソースコードやナレッジのような資産の追跡を助ける。
コミュニティへの参加の妨げを軽減して、コミュニティの成長を促す。
関係するコミュニティとのやりとりを助ける。

具体的には、LaunchpadはあなたのBazaarブランチを管理する無料のコードホスティングサービスであり、ブランチをオンラインで閲覧でき、ブランチとバグやブループリントを関連づけることができ、Bazaarへのコミット時にバグについて記述することによってブランチ-バグ間のステータスを自動的に変更することができます。 すばらしいアイデア を、 エンドユーザの元で実行されるコード にするまでのプロセスを合理化するための、より進んだ統合機能が現在開発中です。

もし、BazaarとLaunchpadがさらにどのように統合されてほしいかについて、何かフィードバックすることがあるのなら、Bazzarメーリングリストで私たちに連絡してください。 bazaar@lists.canonical.com.

Launchpadは自由ソフトウェアプロジェクトをサポートするための無料のサービスとしてデザインされていますが、Canonicalはこれを商業ソフトウェアの開発者にも、その要望次第で提供することができます。オープンソースであってもなくても、Launchpadがあなたのコミュニティの運営に役立つと考えていただけるのならば幸いです。

集中型ワークフローのチュートリアル¶

概要¶

この文書では、 Bazaar を使用することで実現可能なワークフローについて説明します。つまり、分散バージョンコントロールシステムである Bazaar を、集中型のやり方で使用するためのワークフローです。 Bazaar は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、いくつかの異なるワークフローを受け入れることができます。このワークフローは、初めてのユーザでも簡単に Bazaar を使いこなすことができ、分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。

基本的に、この文書はCVSや Subversion のような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、お互いの作業の同期をとることになります。また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。

初期セットアップ¶

Bazaar がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。

ユーザのEメールの設定¶

ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。

% bzr whoami "John Doe <jdoe@organization.com>"

ローカルリポジトリのセットアップ¶

Bazaar のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。最適化の方法の一つとして、関連するブランチ同士の情報を統合して、新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。

そのための一番いい方法は、共用リポジトリを作成することです。一般に、共用リポジトリのサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。ですので、ホームディレクトリに共用リポジトリを作成するようにしましょう。そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。

% bzr init-repo --trees ~

リモートリポジトリのセットアップ¶

作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。) 実際のところ、これは、特に職場ではとてもよい設定です。蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こってもコミットされたデータはけっして無くなりません。

それでは、プロジェクト内で共有する centralhost というマシーンを用意しましょう。先ほども言いましたが、ディスクの使用量を節約するために、共用リポジトリを使用します。

% bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/

この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。 --no-tree オプションの指定によって、ワーキングツリーを作らないようになります。中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。

ここで、 bzr+ssh というURLを使っていますが、これは、 SSH セキュアシェル上の Bazaar 独自プロトコルを意味しています。 bzr+ssh サーバーのセットアップに関する情報に着いては、管理者向けガイドを参照してください。

既存のプロジェクトからの移行¶

リポジトリができましたので、プロジェクトの作成にかかりましょう。たいていの場合、 Bazaar でバージョン管理したい作業中のコードがすでにあるはずです。もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar に変換する方法がたくさんあります。しかしながら、それについてはここでは説明しません。詳しくは、 Tracking Upstream の”Converting and keeping history”セクションを見てください。

Developer 1: 最初のリビジョンを作成する¶

まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。仮に、”sigil”というプロジェクトをバージョン管理しようとしているとしましょう。

% bzr init bzr+ssh://centralhost/srv/bzr/sigil

これは、CVSで言うところの”HEAD”ブランチ、Subversionなら”trunk”にあたるものだと考えてかまいません。これを dev ブランチと呼ぶことにしましょう。

他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。

% cd ~
% mkdir work
% cd work
% mkdir sigil
% cd sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
% cd dev
% cp -ar ~/sigil/* .
% bzr add
% bzr commit -m "Initial import of Sigil"

前のセクションでは、空のブランチ(sigil ブランチ)を centralhost に作成して、それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用のブランチを使った作業が簡単にできます。そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar の長所の一つなのです。

この場合、リモートブランチのチェックアウトを持っているので、 ~/work/sigil/dev/ に対してコミットした内容が、ローカルと centralhost の両方に自動的に保存される訳です。

Developer N: プロジェクトの作業コピーを取得する¶

プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、他のみんなは単にそのブランチをチェックアウトするだけです。 ただし、 ユーザのEメールの設定とローカルリポジトリのセットアップ は見ておいてください。

現在開発中のツリーのコピーを取得するためには:

% cd ~/work/sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev

今、二人の人が bzr+ssh://centralhost/srv/bzr/sigil のチェックアウトを持っている状態なので、片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。コミットの時に、チェックアウトが古いければ Bazaar がエラーを返して、コミットは失敗します。チェックアウトを最新にするには、よそで変更されたツリーに対して bzr update を使用します。この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。

別ブランチでの開発¶

ここまでは、全員が同じブランチで作業して、変更をコミットしていました。これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があるということです。また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、全員が問題を抱えることになります。

たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合するというやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。 CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、ブランチ間できちんと同期がとれた状態に保つのは難しいことです。 Bazaar は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を適用することができます。

新しいブランチを作成してそこで作業する¶

まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。そこで、 centralhost 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。

% cd ~/work/sigil
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
             bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
% cd doodle-fixes

これで、 doodle に必要な修正を当てるための場所ができました。また、他の部分の修正をする人に邪魔されることもありません。チェックアウトを持っているため、 ~/work/sigil/doodle-fixes/ に対してコミットした内容はcentralhost 上にも現れます。 [1] dev ブランチと同じように、このようなブランチ上で二人の開発者が共同で作業することもできます。 [2]

[1]	あるブランチのサブディレクトリに別のブランチがあるというのはおかしなことに見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチから派生しているという点で、名前空間の階層と同じようなものだと考えることができます。

[2]	(1, 2) たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。今のところ、 bzrtools プラグインが `bzr cbranch` コマンドを提供しています。これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成することを少ない入力でできるように設計されています。 `cbranch` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:

% bzr cbranch dev my-feature-branch

変更内容をマージする¶

doodle-fixes での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。:

% cd ~/work/sigil/dev
% bzr merge ../doodle-fixes

これで、変更内容は dev ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。 bzr status コマンドと bzr diff コマンドがここで役立ちます。また、競合を解決するのもこの時です。Bazaar では、競合を解決するまではコミットできないようになっています。そのため、間違って競合マーカーをコミットしてしまうことはありません。 bzr status コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。 bzr conflicts なら、競合の情報だけが表示されます。競合を解決し終わったら、bzr resolve file/name か bzr resolve --all を実行してください。 [3] もし、解決が特に難しい競合がある場合は、 bzr remerge コマンドを使いたいと思うかもしれません。このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示することもできます。(--show-base)

[3]	マージ実行中に競合の解決をさせるシステムもあります。私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単であることに気づきました。そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。

推奨のブランチ構成¶

とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの作業領域を用意するという方法があります。これは以下のコマンドでできます。:

% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
             bzr+ssh://centralhost/srv/bzr/sigil/user-a
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
             bzr+ssh://centralhost/srv/bzr/sigil/user-b

これで、開発者ごとに専用の作業用ブランチを割り当てています。さらに、開発者自身で [2] を使用して新しく新機能開発用ブランチを作成することも簡単にできます。

% bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
             bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
% cd ~/work/sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature

用語解説¶

共用リポジトリ¶

Bazaar には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ旧来の概念に似ています。たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は全くなく、作業ツリーのファイルのチェックアウトがあるだけです。ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。開発者間でも共用される かも知れません が、開発者間での共用はスタンドアロンブランチでも可能です。

Bazaar の用語では、”共用リポジトリ”とは複数のブランチが履歴情報を共有できる場所のことです。分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方がいいためです。

Licence¶

Copyright 2005-2011 Canonical Ltd. Bazaar is free software, and you may use, modify and redistribute both Bazaar and this document under the terms of the GNU General Public License version 2 or later. See <http://www.gnu.org/licenses/>.

日本語訳¶

日本語への翻訳は、 Bazaar-ja <https://groups.google.com/group/bazaar-ja> が行っています。質問や間違いの指摘等はこちらへお願いします。

Bazaarユーザーガイド¶

紹介¶

Bazaarの紹介¶

Bazaarとは？¶

Bazaarはみんなのコラボレーションを手助けするツールです。これは(たとえばソフトウェアのソースコードなどの)ファイルのグループの変化の段階のスナップショットを提供するためにファイルの変更を追跡します。この情報を利用することで、Bazaarはあなたの作業と他の人の作業の成果を簡単にマージします。

Bazaarのようなツールはバージョン管理ツール(version control systems: VCS)と呼ばれ長い間ソフトウェアの開発者の間で人気がありました。 Bazaarは使いやすく、柔軟で簡単にセットアップできるので、ソフトウェアの開発者だけでなく、テクニカルライター、ウェブデザイナー、翻訳者のようなファイルとドキュメントに取り組む人達にも理想的なツールです。

このガイドは、個人で使うのかチームで使うのかに関わらずBazaarのインストールと使い方の手引きをします。すでに分散型のバージョン管理システムに慣れ親しんでおりすぐとりかかりたいのであれば、このセクションを流し読みしてさらに学ぶのセクションに移動するとよいでしょう。

バージョン管理システムの小史¶

バージョン管理ツールは数十年の間に進化してきました。簡単に説明すると、ツールは4世代に渡ります:

ファイルのバージョン管理ツール、たとえばSCCS、RCS

ファイルのバージョン管理ツール - 集中型、たとえばCVS

ファイルのバージョン管理ツール - 第二世代集中型、たとえばSubversion

ファイルのバージョン管理ツール - 分散型、たとえばBazaar

Bazaarの設計と実装は前世代のすべてのツールから学んだことに基づいています。とりわけ、Bazaarは集中型と分散型の両方のバージョン管理モデルをサポートするのでツールを変更せずに複数のモデルに対応できます。

集中型 vs 分散型¶

従来の多くのVCSツールはファイルのツリーに対する履歴(リポジトリ, repository) を提供する中央サーバーが必要です。ファイルに対する作業に取り組むために、ユーザーはサーバーに接続してファイルをチェックアウト (checkout) する必要があります。チェックアウトにより、ユーザーが修正できるツリー(作業ツリー, working tree)ができます。これらの変更を記録(コミット, commit)するためには、集中型のサーバーにアクセスする権限が必要で、コミットをする前に作業内容を最新バージョンとマージしなければなりません。このアプローチは集中型モデルとして知られます。

集中型モデルは長期にわたって有用であることを示してきましたが顕著な欠点がいくつかあります。先ず第一に、集中型のVCSはバージョン管理機能を利用するためにはサーバーに接続できることを要求します。二番目に、集中型のモデルは変更の スナップショットの記録 のふるまいと変更の公開のふるまいと密接にリンクさせます。これは状況によってはよいこともありますが別の状況では品質にわるい影響を与えることがあります。

分散型のVCSツールは単独の集中型のレポジトリではなく複数のレポジトリをユーザーとチームに持たせます。 Bazaarでは通常、履歴はバージョン管理されているコードと同じ場所に保存されます。これによってユーザーは、オフラインであってもコミットするべきタイミングで変更をコミットできます。ネットワークのアクセスは変更を公開するもしくは別の場所の変更にアクセスするときのみ求められます。

実際、分散型VCSツールを賢く使うことでオフライン作業を超えたいくつかの開発者にとっての利点があります。

開発者が実験用のブランチを作るのが簡単になります

仲間とのアドホックなコラボレーションが簡単になります

ルーチンタスクの時間が減ります - より創造的な活動に時間を割けます

“feature-wide” コミットの利用を通してリリース管理の柔軟性が増します

トランクの質と安定性を高い水準で維持でき、それによって作業者のストレスが少なくなります

オープンなコミュニティにおいて:

コア開発者ではない人が作成と変更の維持をしやすくなります

コア開発者が外部の開発者と共同作業をしてコアのチームに組み込むことが楽になります

会社において、分散されたチームや外部のチームと連携するのが簡単になります

分散型VCSツールの集中型より優れた点の詳細な一覧に関しては、 http://wiki.bazaar.canonical.com/BzrWhy を参照してください。

Bazaarの主要な機能¶

Bazaarは現存する唯一のVCSツールではありませんが、多くのチームとコミュニティにとってよい選択肢になる優れた機能をいくつか持ちます。別のVCSツールとの比較の要約はBazaarのWiki、 http://wiki.bazaar.canonical.com で見つかります。

多くの機能の中で、とりわけ強調するものがあります: BazaarはPythonで書かれた完全にフリーなソフトウェアです。結果として、改善に貢献することは簡単です。手を貸して頂けるのであれば、 http://wiki.bazaar.canonical.com/BzrSupport を参照して頂くようお願いします。

さらに学ぶ¶

このマニュアルではBazaarの簡単な紹介と効果的な使い方を提供します。すべてのユーザーは、少なくとも次の点について書かれたこの章の残りを読むことが推奨されます:

ユーザーが知る必要のある中心的な概念を説明します

Bazaarを利用した人気のある方法をいくつか紹介します

2-6章ではさまざまなタスクを実現するためにBazaarを使う方法を詳しく説明します。 Bazaarを使い始めた後で最初から最後まで読むことをほとんどの方にお勧めします。 7章とそれ以降はコアの機能を理解した上でBazaarを利用する際に手助けになる追加情報を提供します。この教材は必要なときに任意の順番で読むことができます。

すでに他のバージョン管理ツールに慣れ親しんでいるのであれば、次のドキュメントを読んですぐに始めるとよいでしょう:

5分でBazaar - ミニチュートリアル

Bazaarクィックスタートカード - よく使われるコマンドを1ページにまとめた要約。

加えて、オンラインのヘルプと Bazaarユーザーリファレンスは利用可能なコマンドとオプションのすべての詳細を提供します。

このマニュアルがお役に立てることを願っております。Bazaarの残りのドキュメントの改善を提案したいのであれば、メーリングリスト(bazaar@lists.canonical.com)に連絡して頂けるようお願いします。

コアの概念¶

単純なユーザーモデル¶

Bazaarを使うために理解する必要のある概念は4つあります:

リビジョン(Revision) - 取り組むファイルのスナップショット
作業ツリー(Working tree) - バージョン管理されたファイルとサブディレクトリを含むディレクトリ
ブランチ(Branch) - ファイルの履歴を記述する、順序づけされたリビジョンの集合
リポジトリ(Repository) - リビジョンの貯蔵場所

それぞれを詳しく見てみましょう。

リビジョン¶

リビジョンはファイルとディレクトリの内容と形を含むそれらのツリーの状態の スナップショット です。リビジョンはそれ自身に関連づけされたメタデータをいくつか含みます。メタデータには次のようなものが含まれます:

コミットした人
コミットした時間
コミットメッセージ
そのリビジョンの元になった親のリビジョン

リビジョンは不変で、グローバルかつユニークに リビジョンid (revision-id) で識別できます。リビジョンidの例は次のとおりです:

pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz

リビジョンidはコミットする、もしくは他のシステムからインポートする時点で生成されます。リビジョンidは内部で利用するときや外部ツールとの統合に必要ですが、ブランチ固有の リビジョン番号 (revision numbers)の方が人間に好まれるインタフェースになります。

リビジョン番号は 1 や 42 や 2977.1.59 のようにドットで区切られた10進法の識別子でブランチに対するリビジョン番号のグラフを通してパスを追跡します。リビジョン番号は一般的にリビジョンidよりも短く、単独のブランチの範囲ではそれらの関係を理解するためにそれぞれを比較できます。たとえば、リビジョン10はリビジョン9の直後のメインライン(下記を参照)のリビジョンです。リビジョン番号はコマンドが実行されているときに生成されます。これらはブランチ内でどのリビジョンがチップ(すなわち最新のリビジョン)であるかに依存するからです。

Bazaarで指定できるリビジョンとリビジョンの範囲のいくつかの方法に関しては、付録のリビジョンを指定するを参照してください。リビジョンの番号付けの詳細に関してはリビジョン番号を理解するを参照してください。

作業ツリー¶

作業ツリー(working tree)はユーザーが編集できるファイルを保持する バージョン管理されたディレクトリ です。作業ツリーは ブランチ に関連付けされます。

多くのコマンドは作業ツリーをそれぞれの文脈で使います。たとえば、 commit コマンドは作業ツリーの中のファイルの現在の内容を利用して新しいリビジョン番号を作ります。

ブランチ¶

最もシンプルな場合、ブランチは 順序づけされた一連のリビジョン です。最終リビジョンは チップ(tip) として知られます。

ブランチは分かれたりその後再結合(marged back)されたりして、グラフの形をとります。技術的にいえば、グラフは(親と子のリビジョンの間)の有行な関係を表し、ループが存在しないので、 directed acyclic graph (DAG) として言及されるかもしれません。

この名前にギョッとするかもしれませんが、ご心配なく。覚えておくべき重要なことは次のとおりです:

DAGの範囲内での開発の主要なラインは メインライン(mineline), トランク(trunk), もしくは単に 左側(left hand side: LHS) と呼ばれます。
ブランチはメインラインではない開発ラインを持つことがあります。そのとき、別のラインはある時点で始まり別の時点で終わります。

レポジトリ¶

レポジトリはシンプルにいえば リビジョンの保管場所 です。最もシンプルな事例では、それぞれのブランチが独自のレポジトリを持ちます。別の事例では、ディスクの使用量を最適化するためにブランチに対してレポジトリを共用しています。

概念をまとめる¶

上記の概念を把握したら、Bazaarのさまざまな使い方が理解しやすくなります。 Bazaarの最もシンプルな使い方は スタンドアロンツリー(standalone tree) で、これは1つの位置に作業ツリー、ブランチとレポジトリのすべてが含まれます。他のよくあるシナリオには次のようなものがあります:

共用リポジトリ(shared branch) - 作業ツリーとブランチは同じディレクトリにありますが、リポジトリは高い階層のディレクトリに存在します。
スタックブランチ(stacked branch) - 親のリポジトリと共通なリビジョンは親のリポジトリのものを利用することで、ブランチはユニークなリビジョンだけを保存します。
軽量チェックアウト(lightweight checkout) - 作業ツリーとは別の場所にブランチが保存されます。

Bazaarを使う最良の方法は、あなたのニーズ次第です。次に共通のワークフローを見てみましょう。

ワークフロー¶

Bazaarはただのツール¶

Bazaarは多くの異なる共同作業の方法を支援します。このことはあるワークフローで始めて状況が変われば別のワークフローを採用できることを意味します。 “唯一の正しい方法”は存在しませんし今後も現れることはりません。このセクションではBazaarによってサポートされる人気のあるいくつかのワークフローの手短な概要を提供します。

これらのワークフローはBazaarの使い方の一部であることを念頭にお願いします。ここに記載されていないワークフローを利用したいのであれば、下記に記載されているアイディアを足場にします。

ソロ¶

ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを変更するのであれ、簡単に使えるVCSは手助けになります。投稿者が1人であるプロジェクトを複数管理するために単独のユーザーはこのワークフローを効率的に利用できます。

まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:

古いバージョンのバックアップ

前の状態へのロールバック

履歴の追跡

このワークフローに適切なBazaarの主要な機能は管理作業が少ない(サーバーのセットアップは不要)ことと簡単に利用できることです。

パートナー¶

時に2人で変更を共有して共同作業をする必要があります。これは一般的にソロのワークフロー (上記を参照) もしくはチーム指向のワークフロー(下記を参照)として始まります。ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含むブランチを作ります。適切なときにマージして変更内容を交換することで並行して作業できます。

ソロを上回る利点は次のとおりです:

変更の共有が簡単

それぞれのテキストファイルのそれぞれの行は変更した人、時間と理由を含む特定の変更と結びつけられています。

このワークフローを採用する場合、BazaarはCVSとSubversionに対して次のような利点があります:

サーバーのセットアップが不要

インテリジェントなマージ機能により複数回のマージ作業が苦痛ではなくなります。

集中型¶

lock-step としても知られますが、これはCVSとSubversionによって推奨/強制されるワークフローと本質的に同じです。すべての開発者が同じブランチに取り組みます。最新の内容をチェックアウトするために bzr update を実行し、変更内容を中心位置にコミットするために bzr commit を実行します。

このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。 Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点をいくつかもちます:

よりよいブランチとマージ

よりよいリネームのサポート

ローカルなコミットで集中型¶

このワークフローは、開発者が commit --local もしくはチェックアウトをunbindして一連の変更を行うこと以外は、 集中型 モデルと基本的に同じです。こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインにコミットします。

集中型 を越える利点:

旅行の間にネットに接続していないなどのオフラインで作業できます

誰かの作業を妨げる良くないコミットをする機会が少なくなります

SubversionとCVSはこのモデルをサポートしません。他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。

共用のメインラインで分散型¶

このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、加えてメインブランチにコミットする権限があります。開発者は個人のブランチに取り組み、準備ができたらそれをメインラインにマージします。

ローカルコミットつきの集中型 を越える利点は次のとおりです:

作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。

開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。

SubversionとCVSはこのモデルをサポートしません。他の分散型VCSツールはサポートします。 Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能とリッチなメタデータ(ディレクトリのリネームの追跡を含む)を含めてこのワークフローに有効です。

人間のゲートキーパーで分散型¶

このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。 1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。 1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーにマージしてくれるように頼みます。ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば作業内容をメインブランチにマージします。

共用のメインラインによる分散型 に対する利点は次のとおりです:

常にコードはメインラインに入る前にレビューされます。

変更をメインラインに組み込むときに厳格なコントロールができます

Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更がレビュー待ちになっているのか、その変更のステータスとレビューアのコメントを追跡するのにとても便利です。

自動的なゲートキーパーで分散型¶

このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、メインストリームにリードオンリーのアクセス権限を持ちます。ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。レビューに合格したら、チームの方針によって、オリジナルの著者もしくはレビューワがゲートキーパーソフトウェアにマージするように頼み、ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。

注: 代替として、レビューのステップをスキップして著者は変更を自動化されたゲートキーパーに投稿できます。 (これはコードのレビューを別のステップとしてではなくジャストインタイムのレビューを効果的に推進するペアプログラミングといった習慣を利用しているときにとりわけ適切です。)

人間のゲートキーパーによる分散型 に対する利点は次のとおりです:

コードはメインラインに入る前に常にテストされます (メインラインの完全性が高まります)

チームの規模の成長に対応できます

BazaarのコンパニオンツールであるPatch Queue Manager (PQM) は自動化ゲートキーパーの機能を提供します。

ワークフローを実施する¶

上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、このマニュアルの3章から6章までを参照してください。最初に、2章で、インストール方法、一般的な使い方の手引きと設定方法に関するティップスが説明されています。

始める¶

Bazaarをインストールする¶

GNU/Linux¶

Bazaar のパッケージは Ubuntu/Debian, Red Hat と Gentoo を含む人気のある大抵の GNU/Linux ディストリビューションで利用できます。最新の手引きは http://wiki.bazaar.canonical.com/Download を参照してください。

Windows¶

Windowsユーザーは、Bazaarのコアパッケージと一緒に必要な前提要件といくつかの便利なプラグインを含むインストーラが利用できます。最新の手引きは http://wiki.bazaar.canonical.com/Download を参照してください。

注: Windows上でCygwinを動かしている場合、Cygwin用のBazaarパッケージをWindows版の代わりに使わなければなりません。

他のオペレーティングシステム¶

BazaarのパッケージはLinuxとWindowsだけでなく、Mac OS X, FreeBSD, Solarisを含む広い範囲のオペレーティングシステムで利用可能です。最新の手引きに関しては http://bazaar-vcs.org/Download を参照してください。

ゼロからインストールする¶

予めビルドされたパッケージよりもソースからBazaarをビルドしたい場合、手順は次のとおりです:

まだインストールしていなければ、バージョン2.4以降のPythonをインストールします。

http://wiki.bazaar.canonical.com/Download もしくは Launchpad (https://launchpad.net/~bzr/)から bazaar-xxx.tar.gz ファイル (xxxはバージョン番号)をダウンロードします。

tar、WinZipもしくは同等のコマンドを用いてアーカイブを解凍します。

作成されたディレクトリをPATHに登録します。

インストールが成功したことを確認するために、次のように bzr コマンドを試します:

bzr version

このコマンドによってインストールされているBazaarのバージョンが表示されます。このコマンドが動作しない場合、開発者が正常な動作の手助けをできるように EメールかIRCを通して開発者に連絡をして頂くようお願いします。

site-wide な場所にインストールする¶

ディレクトリにPATHを設定する代わりに、次のコマンドでにbzrをインストールすることができます。:

python setup.py install

もしあなたがコンパイラやPythonの開発ツールを持っていない場合、 bzrは全ての拡張モジュールに対して(遅い)pure-pythonの実装を提供します。次のコマンドを使って拡張モジュールのコンパイルなしにインストールできます:

python setup.py install build_ext --allow-python-fallback

開発バージョンを稼働させる¶

Bazaarの最新の開発バージョンを常に利用したい場合があります。バグの危険性が増すので大半のユーザーにはお勧めできないことに注意してください。一方で、開発バージョンは(開発プロセスのおかげで)非常に安定しているので、これを動かすことで、バグと改善内容のための変更内容を開発者に送ることが楽になります。より多くの人が最新のソフトウェアをテストすることで開発者の手助けにもなります。

従うべき手順は次のとおりです:

上記の方法の1つを利用してBazaarをインストールする。
次のように開発バージョンのコピーを入手します:
bzr branch http://bazaar-vcs.org/bzr/bzr.dev
作成されたディレクトリ(bzr.dev)をPATHに登録します

上級ユーザーはより早く動かすためにC言語の拡張機能をビルドもしたいことでしょう。これは make と pyrex とCコンパイラを利用することで実現できます。このことに関して手助けが必要であればEメールかIRCを通して連絡をして下さるようお願いします。

複数のバージョンを稼働させる¶

Bazaarの複数のバージョンをインストールしてそれらを切り替えることは簡単です。これを行うためには、実行したい bzr のフルパス名を入力するだけです。関連ライブラリは自動的に検出されます。もちろん、パス名を提供しない場合、通常のシステムパスで見つかる bzr のコマンドが使われます。

この機能は最新バージョンと開発バージョンの両方を走らせたい(テストしたい)場合にとりわけ役立ちます。

コマンドを入力する¶

ユーザーインターフェイス¶

Bazaarに対して利用可能な数多くのユーザーインターフェイスが存在します。コアパッケージは bzr と呼ばれるコマンドラインツールを提供しグラフィカルユーザーインターフェイス(GUI)はプラグインとして利用できます。

bzrを使う¶

構文は次のとおりです:

bzr [グローバルオプション] command [オプションと引数]

グローバルオプションはBazaarの動作方法に影響を与え command の前後に現れます。コマンド特有のオプションはコマンドの後で指定しなければなりませんが、コマンド固有の引数の前後と間で指定することができます。

共通のオプション¶

下記で示されるいくつかのオプションはすべてのコマンドに対して有効です。

短い形式長い形式説明

-h –help get help

-v –verbose be more verbose

-q –quiet be more quiet

Quietモードはエラーと警告のみを表示します。これはスクリプトで使う際に便利です。

注: 大抵のコマンドは1つのレベルの冗長性だけをサポートします。今後これは変更されるかもしれません。高度な冗長性を求めるためには、-vオプションを複数回指定するだけです。

helpを表示する¶

Bazaar は組み込みのオンラインヘルプシステムを搭載していて、次のコマンドでアクセスできます。

bzr help

help コマンドで、コマンドやコマンド以外のトピックに着いて調べることができます。それぞれのヘルプの一覧を見るには次のようにします。

bzr help commands
bzr help topics

特定のコマンドのヘルプを見るには、次の２つの形式を使うことができます。

bzr help status
bzr status --help

ヘルプを検索するもしくは大きなドキュメントとして読みたい場合、情報はBazaarのユーザーリファレンスでも手に入ります。

Bazaarを設定する¶

Bazaarにあなたの名前を教える¶

バージョン管理システムの機能の1つは誰が何を変更したのかを追跡することです。分散型のシステムでは、その機能を実現するためにグローバルにユニークなそれぞれの著者のための識別子が必要です。大抵の人はそれらの1つを持っています: Eメールアドレスです。 Bazaarはあなたのユーザー名とホスト名を探し出してEメールアドレスを自動的に生成します。 Bazaarが行う推測を望まないのであれば、あなたが望む識別子を設定するために whoami コマンドを使います:

% bzr whoami "Your Name <email@example.com>"

whoami は引数なしで使われると、現在の値が表示されます。

ネットワークプロクシを使う¶

ネットワークが外部への接続に HTTP プロクシを必要とする場合、 http_proxy という環境変数を設定しなければなりません。 https 接続にもプロクシが必要なら、 https_proxy も設定しなければなりません。プロクシが必要なのにこれらの環境変数が設定されていない場合、 Launchpad やその他の外部のサーバーへの接続ができなかったりタイムアウトしたりします。

Unix では、たいていこれらの設定は /etc/environment か ~/.bash_profile に書いて、 Windows ではたいていユーザープロファイルで設定します。

http_proxy=http://proxy.example.com:3128/
https_proxy=http://proxy.example.com:3128/

The no_proxy variable can be set to a comma-separated list of hosts which shouldn’t be reached by the proxy. (See <http://docs.python.org/library/urllib.html> for more details.)

no_proxy という環境変数に、プロクシを利用しないで到達するホスト名のリストをカンマ区切りで設定できます。 (詳細は <http://docs.python.org/library/urllib.html> を参照してください)

いろいろな設定方法¶

上の例で示したように Bazaar を設定する方法はたくさんありますが、全てに共通している属性があります。オプションは全て以下のようになっています。

名前は有効な Python の識別子です。
a value which is a string. In some cases, Bazaar will be able to recognize special values like ‘True’, ‘False’ to infer a boolean type, but basically, as a user, you will always specify a value as a string.
値は文字列です。いくつかの場面では、真偽値を得るために Bazaar は True, False のような特別な値を認識しますが、基本的にはユーザーは値としてただの文字列を渡します。

オプションはコンテキストによってグループ化されており、オプション名はそのコンテキスト内ではユニークに識別することができます。必要な場合、オプションは設定ファイルに保存され永続化されます。

設定ファイル¶

設定ファイルは Unix の場合 $HOME/.bazaar に、 Windows の場合 C:\Documents and Settings\<username>\Application Data\Bazaar\2.0 にあります。この場所には3つの主要な設定ファイルがあります:

bazaar.conf はデフォルトの設定オプションを記述します。
locations.conf は特定のブランチの位置を記述しますd
authentication.conf はリモートサーバーのためのクレデンシャルな情報を記述します

それぞれのブランチも特定の値をそのブランチに設定する設定ファイルを含みます。このファイルはブランチの中の .bzr/branch/branch.conf で見つかります。このファイルは ブランチのすべてのユーザー に見えます。あなたに固有の設定を持つブランチのための値の1つを上書きしたいのであれば、 locations.conf でそれを行うことができます。

whoami コマンドを使用してEメールアドレスを設定した後の bazaar.conf の内容のサンプルは次のとおりです:

[DEFAULT]
email = Your Name <email@example.com>

サポートされる構文と構成設定の詳細については、 Bazaar のユーザーリファレンスの構成設定の項目を参照してください。

アクティブな設定を確認する¶

現在定義されている全てのオプションを確認するには、次のコマンドを実行します。

bzr config

bzr は設定オプションをどこから取得するかを決定するためのいくつかのルールを持っています。

現在のポリシーでは、以下の順序でマッチする定義を設定ファイルから探します。

最初に location.conf の中の、セクション名が場所(作業ツリー、ブランチ、リモートブランチ)にマッチするセクションが探されます。

次に現在の branch.conf が探されます。

次に bazaar.conf が探されます。

最後に、いくつかのオプションはコード中で定義されたデフォルト値が設定され、この設定は bzr config には表示されません。 (構成設定を参照してください。)

この動作は、 bzr config を引数なしで実行すると理解しやすいはずです。このコマンドを実行すると次のような表示をします。

locations:
  post_commit_to = commits@example.com
  news_merge_files = NEWS
branch:
  parent_location = bzr+ssh://bazaar.launchpad.net/+branch/bzr/
  nickname = config-modify
  push_location = bzr+ssh://bazaar.launchpad.net/~vila/bzr/config-modify/
bazaar:
  debug_flags = hpss,

各オプション定義のグループの前に表示されているスコープが、そのオプションを定義している構成設定ファイルを表しています。

有効な設定を変更する¶

オプションに値を設定するには:

bzr config opt=value

オプションの利用を止めるには:

bzr config --remove opt

ルールベースのプリファレンス¶

いくつかのコマンドとプラグインは特定のパターンにマッチするファイルのカスタムの処理機能を提供します。ユーザーごとにルールベースのプリファレンスが BZR_HOME/rules で定義されます。

ルールが検索される検索方法と関連ファイルの詳細な構文に関する詳細については、 Bazaarのユーザープリファレンスのルールの項目を参照してください。

コマンドラインのエスケープ¶

設定ファイルの中にプログラム名やコマンドラインを記述する場合、特殊な文字やスペースをその中に含めるためにクォートすることができます。同じルールが全てのプラットフォームで有効です。

そのルールとは、ダブルクォートで囲まれた文字列はスペースが含まれていたとしても 1つの「語」として認識され、クォート文字をクォートの中に含めるためにバックスラッシュ (訳注: 日本語環境では多くの場合バックスラッシュではなく円記号(ASCII文字の0x5c)です) を使います。例えば:

BZR_EDITOR="C:\Program Files\My Editor\myeditor.exe"

エイリアスを利用する¶

エイリアスとは？¶

エイリアスは良く入力するコマンド用のショートカットを作るもしくはコマンド用のデフォルトを設定するための手軽な方法です。

エイリアスを定義する¶

コマンドのエイリアスは bazaar.conf ファイルの [ALIASES] セクションで定義されます。エイリアスはエイリアスの名前で始まり、等号(=)、コマンド列が続きます。次のコードはALIASESセクションの例です:

[ALIASES]
recentlog=log -r-3..-1
ll=log --line -r-10..-1
commit=commit --strict
diff=diff --diff-options -p

上記の例の説明は次のとおりです:

最初のエイリアスは最新の3つのリビジョンに対するログを表示する新しい recentlog コマンドを作ります

ll エイリアスは行形式で最新の10件のログエントリを表示します。

commit エイリアスはツリーの中の新しいファイルが認知されない場合コミットを拒絶するデフォルトのcommitを設定します。

diff エイリアスは -pオプションをdiffに追加します

定義したエイリアスを利用する¶

上記で定義されたエイリアスは次のように使われます:

% bzr recentlog
% bzr ll
% bzr commit
% bzr diff

エイリアスのためのルール¶

コマンドライン上で新しいオプションを指定することでエイリアスに渡されるオプションの一部をオーバーライドできます。たとえば、 lastlog -r-5.. を実行すると 10の代わりに行ベースのログエントリが5つだけ得られます。すべての論理値型のオプションは暗黙的に逆のオプションがあるので、 commit --no-strict でcommitのエイリアスをオーバーライドできます。

エイリアスの名前をオリジナルのコマンドと同じものにすることでエイリアスは既存のコマンドの標準のふるまいをオーバーライドできます。たとえば、デフォルトのコミットは commit=commit --strict で変更されます。

エイリアスは他のエイリアスを参照できません。言い換えるとエイリアスの lastlog を作りそれを ll で参照しても動作しません。これは標準のコマンドをオーバーライドするエイリアスを含みます。

　 --no-aliases オプションをbzrのコマンドに渡すと実行時にエイリアスは無視されます。たとえば、 bzr --no-aliases commit を実行すると commit --strict ではなく標準のcomitコマンドが実行されます。

プラグインを利用する¶

プラグインとは？¶

プラグインは主にサードパーティによって作られたBazaarのための外部コンポーネントです。プラグインは新しい機能を追加することでBazaarを補強する能力があります。プラグインは現在の機能を置き換えることでBazaarのふるまいを変更することもできます。プラグインのサンプルのアプリケーションは次のとおりです:

コマンドをオーバーライドする
新しいコマンドを追加する
追加のネットワーク転送機能を提供する
ログの出力をカスタマイズする

プラグインを通してできるカスタマイズの可能性は際限がありません。実際、開発者が新しい機能を公式のコードベースに含める前にテストするための方法としてプラグインは機能します。プラグインは機能の引退時でも同様に役立ちます。たとえば廃止されたファイルのフォーマットがある日Bazaarのコアから除外されるかもしれませんが代わりにプラグインとして利用できます。

プラグインはユーザーにとって、外部の開発者にとっても、Bazaar自身にもよいものです。

プラグインが見つかる場所¶

http://wiki.bazaar.canonical.com/BzrPlugins ページでプラグインのリストが見つかります。

プラグインをインストールする方法¶

プラグインのインストール作業はとても簡単です！　まだ作られていなければ、 Bazaarの設定ディレクトリの元で plugins ディレクトリを作ります。 Unix の場合は ~/.bazaar/ でWindowsの場合は C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\ です。このディレクトリの範囲内では(下記では$BZR_HOMEとして言及される) それぞれのプラグインは独自のサブディレクトリに設置されます。

プラグインはとりわけBazaarのブランチとよく連携します。たとえば、 GNU/Linux のメインのユーザーアカウント用に bzrtools プラグインをインストールするためには、次のコマンドを実行します:

bzr branch http://panoramicfeedback.com/opensource/bzr/bzrtools
~/.bazaar/plugins/bzrtools

プラグインをインストールするディレクトリの名前はPythonの有効な識別子でなければなりません。このことはディレクトリは特定の文字だけを含まなければならないことを意味します。とりわけハイフン (-) を含んではなりません。 bzr-gtk を $BZR_HOME/plugins/bzr-gtk にインストールするよりも、 $BZR_HOME/plugins/gtk にインストールします。

プラグインの代替用の場所¶

必要なパーミッションがあれば、プラグインをシステム全体のベースにインストールすることもできます。

環境変数 BZR_PLUGIN_PATH をプラグインが含まれるディレクトリに設定することで個人のプラグインの場所を上書きできます。 (詳細な解説はユーザーリファレンスを参照してください。)

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

これを行うためには、次のようにpluginsコマンドを使います:

bzr plugins

それぞれのプラグインの名前、場所とバージョンが表示されます。

プラグインによって追加された新しいコマンドは bzr help commands を実行することで見ることができます。プラグインによって提供されたコマンドはブラケットの中のプラグインの名前に従って表示されます。

Bazaarの哲学¶

Bazaarを完全に理解する¶

Bazaarは多くの点で他のVCSに似ていますが、最初見たときに必ずしも明らかではない大きな違いがいくつかあります。このセクションでは Bazaarを”grok”するため、すなわち深く理解するために、ユーザーが知る必要のあるいくつかの内容の説明を試みます。

注: Bazaarを使うためにこのセクションを十分に理解する必要はありません。このセクションをさっと読んで後で戻るとよいでしょう。

リビジョン番号を理解する¶

ブランチのメインラインのすべてのリビジョンは単純に増加する整数を持ちます(最初のコミットは1、10番目のコミットは10などです)。これによって “私のブランチから10番目のリビジョンを獲得する”、もしくは “リビジョン3050で修正した” という言い方が自然になります。

ブランチにマージされるリビジョンに関しては、ドットつきのバージョンが使われます(たとえば、3112.1.5)。ドットつきのリビジョン番号は3つの番号を持ちます [1]. 最初の番号はメインのリビジョンの変更の由来を示します。 2番目の番号はブランチのカウンターです。同じリビジョンから多くのブランチが由来することがあり得るので、それらのブランチはユニークな番号を取得します。 3番目の番号はブランチの開始以降のリビジョン番号です。たとえば、3112.1.5はリビジョン3112からの最初のブランチで、そのブランチ上の5番目のリビジョンです。

[1]	バージョン1.2以前のbzrでは少し異なるアルゴリズムが使われていました。いくつかの入れ子のブランチはよりシンプルな3つの番号システムではなく追加の番号(たとえば1.1.1.1.1)を取得します。

階層形式の履歴はよいものである¶

多くの変更が一連のコミットで構成される状況で複数の開発者が変更を投稿するプロジェクトを想像してください。具体例を示すために、次の事例を考えてみましょう:

プロジェクトのトランクのチップはリビジョン100です。

Maryは機能Xを配信するために3つの変更を行う

Billは機能Yを配信するために4つの変更を行う

開発者が並行して作業して伝統的な集中型のVCSのアプローチを利用する場合、大抵の場合プロジェクトの履歴は次のようにMaryの変更とBillの変更が交互に混ざります:

Add documentation for Y
Fix bug found in testing Y
Fix bug found in testing X
Add code for Y
Add documentation for X
Add code and tests for X
Add tests for Y
...

多くのチームはこのアプローチを利用します。彼らのツールではブランチの作成とマージが難しいからです。結果として、開発者はトランクからの更新とコミットを頻繁に行い、すべてのコミットを通してそれを広げることで統合の苦痛を最小化します。望むのであれば、このようにBazaarを使うことができます。 Bazaarは考慮すべき別の方法を提供します。

分散型のVCSツールによって推奨される代替のアプローチは機能ブランチを作り、準備ができたらそれらを統合することです。この場合、Maryの機能ブランチは次のようになります:

Fix bug found in testing X
Add documentation for X
Add code and tests for X
...

そしてBillのものは次のようになります:

Add documentation for Y
Fix bug found in testing Y
Add code for Y
Add tests for Y
...

機能が独立していてリニアな履歴を維持したいのであれば、変更はバッチでトランクにpushされます。 (技術的には、これを行う方法は無数にありますがこの検討内容の範囲を超えます。) 結果の履歴は次のようになります:

Fix bug found in testing X
Add documentation for X
Add code and tests for X
Add documentation for Y
Fix bug found in testing Y
Add code for Y
Add tests for Y
...

これを実現するために少し努力が必要な一方で、リビジョンをランダムに織り交ぜるよりもいくつかの利点があります。よりベターですが、non-linearな履歴を形成してブランチは一緒にマージできます。結果は次のようになります:

Merge feature X
2.3: Fix bug found in testing X
2.2: Add documentation for X
2.1: Add code and tests for X
Merge feature Y
1.4: Add documentation for Y
1.3: Fix bug found in testing Y
1.2: Add code for Y
1.1: Add tests for Y
...

もしくは次のようになります:

Merge feature X
2.3: Fix bug
2.2: Add documentation
2.1: Add code and tests
Merge feature Y
1.4: Add documentation
1.3: Fix bug found in testing
1.2: Add code
1.1: Add tests
...

多くの理由からこれはよいものと考えられます:

プロジェクトの履歴を理解するのが楽になります。関連した変更はクラスターを形成し明確に区切られます。

ブランチのメインライン上のコミットだけを見るために履歴を簡単に折りたたむことができます。 (このレベルでは興味のない膨大な数のコミットの代わりに) このようなトランクの履歴を閲覧するとき、高いレベルのコミットだけ見えます。

必要であれば、より簡単に機能の変更を取り消します

継続的インテグレーション(Continuous integration: CI)ツールはマージをメインラインにコミットするためにすべてのテストが合格することを保証するために使われます。 (多くの場合、すべての単独のコミットの後でCIツールの引き金を引くのは適切ではありません。テストの中には開発の間に失敗するものがあるからです。実際、テストファーストの追加 - テスト駆動開発(TDD)のスタイル - によってこれが保証されます！)

要約すると、重要な点は次のとおりです:

ブランチを利用してあなたの作業内容を編成する

マージ機能を利用して変更を統合する

順序つきの番号と階層によって履歴を追跡するのが楽になる

それぞれのブランチは履歴の独自のビューを持つ¶

上述のように、Bazaarは次の内容を区別します:

メインラインのリビジョン、すなわちブランチにコミットしたもの

マージしたリビジョン、マージをコミットすることで祖先として追加されるもの

それぞれのブランチは効率的に履歴の独自ビューを持ち、すなわち、異なるブランチは同じリビジョンに異なる”ローカルな”リビジョン番号を与えます。

マージされたリビジョンは常にドットつきのリビジョン番号を入手するのに対してメインラインのリビジョンは常に単独の数字のリビジョン番号が割り当てられます。

上記の例を拡張するためには、Maryが変更を完了させた後でプロジェクトのトランクにマージした後に Maryのブランチのリビジョンの履歴は次のようになります:

Merge mainline
2.1: Merge feature Y
1.4: Add documentation
1.3: Fix bug found in testing
1.2: Add code
1.1: Add tests
Fix bug found in testing X
Add documentation for X
Add code and tests for X
...

繰り返しますが、Maryはこの変更を開発するためにステップを見るために彼女の履歴のトップレベルを調べることが簡単になります。この文脈では、トランクのマージ(とそれを行うことによる衝突の解消)はこのブランチの履歴に関しては単なる1つのステップです。

Bazaarは履歴を変更するのでなければグローバルなリビジョン識別子を変更するのでもないことを覚えておくのは大事です。本当に望むのであれば常に後者を使用できます。実際、ブランチのURLをコンテクストとして提供する限りコミュニケーションをするときに特定のリビジョン番号を使うことができます。 (多くのBazaarのプロジェクトでは、開発者はブランチURLなしでリビジョン番号を交換するとき中心のトランクのブランチをほのめかします)

マージはブランチのリビジョン番号を変更しません。それらはローカルのリビジョン番号を新しくマージしたリビジョンに割り当てるからです。 Bazaarがブランチのリビジョン番号を変更する唯一のときはあなたが明示的に別のブランチをミラーリングするように頼むときです。

注: リビジョンは安定した方法で番号づけされます: 2つのブランチがメインラインで同じリビジョン番号を持つとき、そのリビジョンの祖先のすべてのリビジョンは同じリビジョン番号を持ちます。たとえば、AliceとBobのブランチがリビジョン10に一致するのであれば、それらはそれ以前のすべてのリビジョンで一致します。

要約¶

一般的に、前に示されたアドバイスに従うのであれば - ブランチの中で作業し、連携するためにマージを使う - Bazaarが一般的にあなたが期待することを行うことがわかります。

次の章では、Bazaarを利用したさまざまな方法: もっとも単純なプロジェクト、個人プロジェクトなどを試します。

個人用途のバージョン管理¶

単独で始める¶

個人の生産性を向上させるツール¶

ツールの中には個人を生産的にする(たとえばエディタ)ためやチームもしくは会社全体を生産的にする(たとえばバックエンドサービス)ために設計されたものがあります。バージョン管理ツールは伝統的に後者の陣営にありました。

Bazaarがクールであることの1つはセットアップが簡単なのでバージョン管理ツールを個人の生産性を上げるツールとして扱うことができることです。既知のよい状態であるかチェックする、もしくは履歴を追跡するために変更を保存したい場合、簡単に行うことができます。この章では方法を説明します。

単独用途のワークフロー¶

あなた独自の名作を作っているのであれば、ソフトウェア、プロジェクトもしくはドキュメントの一式であれ、典型的なワークフローは次のようになります:

チームの一員として常に作業をするとしても、この章でカバーされるタスクはあなたが行うことの基本になるので、よいスタート地点です。

プロジェクトを始める¶

既存のプロジェクトをバージョン管理する¶

バージョン管理下に置きたいソースコードのツリー(ドキュメントのディレクトリ)をすでにお持ちなら、使うコマンドは以下のとおりです:

cd my-stuff
bzr init
bzr add
bzr commit -m "Initial import"

bzr init はトップレベルのディレクトリで .bzr ディレクトリを作ります(上記の例では my-stuff )。次のことに注意してください:

Bazaarは必要なすべてのものをそのディレクトリに置きます - データベース、ウェブサーバー、特別なサービスをセットアップする 必要はありません

Bazaarは .bzr を1つのディレクトリだけに作り、他のすべてのサブディレクトリの中には作らないぐらい礼儀正しいです。

bzr add はバージョン管理化におくべきと考えられるすべてのファイルとディレクトリを見つけ内部で登録します。 bzr commit はこれらの内容のスナップショットとその情報をコミットメッセージと一緒に記録します。

init 、 add と commit に関する詳細な情報は後で提供します。現時点で、覚えておくべき大事なことは上記のレシピです。

新しいプロジェクトを始める¶

プロジェクトをゼロから始める場合、最初の段階で空のディレクトリを作った後で上述のレシピを使うこともできます。後の章で詳しく探求する効率の理由から、プロジェクトのためにトップレベルでレポジトリを作りその中で メイン のブランチを入れ子にすることはよいアイディアです。次のようになります:

bzr init-repo my.repo
cd my.repo
bzr init my.main
cd my.main
hack, hack, hack
bzr add
bzr commit -m "Initial import"

main の代わりに trunk もしくは dev のような名前を好む人もいます。何であれあなたにとって最も有用な意味のある名前を選んでください。

init-repo と init コマンドの両方はパスを引数としてとり、すでに存在していなければそのパスを作ることに留意してください。

ファイルの登録を制御する¶

Bazaarは何を追跡するのか？¶

前に説明したように、 bzr add は現在のディレクトリの元でBazaarがバージョン管理すべきだと考えるすべてのものを見つけ登録します。登録するものは次のようなものになります:

ファイル

ディレクトリ

シンボリックリンク

Bazaarは興味を持つファイルと興味を持たないファイルに関してデフォルトのルールを持ちます。後で説明されるファイルを無視するのようにこれらのルールを調整できます。

他の多くのVCSツールとは異なり、Bazaarはディレクトリを第一級の項目として扱います。結果として、空のディレクトリは正しくサポートされます - ディレクトリが追跡されプロジェクトのエクスポートに含まれることを保証するためにディレクトリ内部にダミーファイルを作る必要はありません。

シンボリックリンクに関しては、シンボリックリンクの値は追跡され、シンボリックリンクが指し示すものの内容は追跡されません。

注: プロジェクトの中のプロジェクトを追跡するサポート機能 (“入れ子ツリー”) は現在開発中です。この機能の開発を手伝うもしくはテストすることにご興味がありましたらBazaarの開発者に連絡して下さるようお願いします。

登録を選ぶ¶

いくつかの事例において、登録したいものをBazaarに発見を任せるよりも明示的に指名したいことがあります。これを行うためには、パスを引数として add コマンドに提供します:

bzr add fileX dirY/

ディレクトリを追加すると暗黙的にそのディレクトリの中の関心のあるすべてのものが追加されます。

ファイルを無視する¶

エディタのバックアップ、オブジェクト、バイトコードのファイル、ビルドされたプログラムなど、多くのソースツリーはバージョン管理する必要のないファイルを含みます。単純にこれらを追加しないでおくと、これらは常に未知のファイルとして現れます。ツリーのトップでこれらを .bzrignore と呼ばれるファイルに追加することでBazaarにこれらのファイルを無視するように指示することもできます。

このファイルは一行ごとにファイルのワイルドカード(もしくは “globs”)の一覧を含みます。典型的な内容は次のとおりです:

*.o
*~
*.tmp
*.py[co]

globがスラッシュを含む場合、ツリーのトップからのパス全体がマッチします; さもなければファイルの名前だけにマッチします。以前の例ではすべてのサブディレクトリ内の . の拡張子を持つファイルが無視されますが、次の例ではトップレベルでは config.h だけと doc/ の中のHTMLが無視されます:

./config.h
doc/*.html

どのファイルが無視され何のパターンにマッチするのかについての一覧表を得るためには、 bzr ignored を使います:

% bzr ignored
config.h                 ./config.h
configure.in~            *~

無視するパターンがバージョン管理されていないファイルのみにマッチし、それらが”unknown”もしくは”ignored”として扱われるのかを制御します。ファイルが明示的に追加されると、無視するパターンにマッチするかに関わらずバージョン管理されたままです。

.bzrignore ファイルは通常はバージョン管理されるので、ブランチの新しいコピーは同じパターンを見ます:

% bzr add .bzrignore
% bzr commit -m "Add ignore patterns"

bzr ignore PATTERN コマンドはPATTERNを .bzrignore ファイルに手軽に追加するために使われます (必要でBazaarによって追跡するために登録する場合、作られます)。 .bzrignore ファイルを直接編集することでパターンの除去と修正が行われます。

グローバルで無視する¶

プロジェクト固有のものではないが、ユーザー固有の無視されるファイルがいくつかあります。編集者用の一時ファイルもしくは個人の一時ファイルのようなものです。これらを無視するようにすべてのプロジェクトに追加するよりも、 bzrは ~/.bazaar/ignore の中でグローバルで無視するファイルをサポートします [1] 。これはプロジェクト単位で無視するファイルと同じ構文を持ちます。

[1]	Windowsにおいて、ユーザーの設定ファイルはアプリケーションデータディレクトリで見つかります。 `~/.bazaar/branch.conf` の代わりに、設定ファイルは次のように見つかります: `C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf` 同じことが `locations.conf` 、 `ignore` 、と `plugins` ディレクトリにも当てはまります。

変更をレビューする¶

リープする前にロックする¶

作業が完了したら、恒久的に記録することに先駆けて変更をレビューするのはよい考えです。この方法で、何を意図しているのかをコミットすることを確認できます。

2つのbzrコマンド: status と diff はとりわけ便利です。

bzr status¶

status コマンドは最後のリビジョン以降に作業ディレクトリに行われた変更内容を伝えます:
% bzr status
modified:
   foo

bzr status は変更されないもしくは無視される “つまらない” ファイルを隠します。 statusコマンドはチェックするためにオプションとしてファイルもしくはディレクトリの名前を渡すことができます。

bzr diff¶

The diff コマンドはすべてのファイルへの変更の全文を標準のunified diffとして表示します。これは ‘’patch’‘、 ‘’diffstat’‘、 ‘’filterdiff’’ と ‘’colordiff’‘といった多くのプログラムを通してパイプで引き渡すことができます:

% bzr diff
=== added file 'hello.txt'
--- hello.txt   1970-01-01 00:00:00 +0000
+++ hello.txt   2005-10-18 14:23:29 +0000
@@ -0,0 +1,1 @@
+hello world

-r オプションによって、ツリーは前のリビジョン、もしくは示された2つのリビジョンの違いを表示します:

% bzr diff -r 1000..          # r1000 からの全ての変更
% bzr diff -r 1000..1100      # 1000 から 1100 までの変更

1つのリビジョンの変更だけを見たい場合は、 -c オプションを利用します。

% bzr diff -c 1000            # r1000 による変更
                              # -r999..1000 と同じ意味

--diff-options オプションによってbzrは外部のdiffプログラムにオプションを渡して実行します。例です:

% bzr diff --diff-options --side-by-side foo

プロジェクトの中には新旧のファイルのためのパスの始めで接頭辞を表示するためにパッチを好むところもあります。 --prefix オプションはそのような接頭辞を提供するために使われます。ショートカットとして、 bzr diff -p1 は patch -p1 コマンドで機能する形式を生み出します。

変更を記録する¶

bzr commit¶

作業ツリーの状態が満足のゆくものであるとき、これをブランチに コミット できます。そしてその状態のスナップショットを保持する新しいリビジョンが作られます。

commit コマンドはリビジョンの変更を記述するメッセージをとります。コミットはあなたのユーザーID、現在の時間とタイムゾーン、一覧表とツリーの内容も記録します。コミットメッセージは -m もしくは --message オプションによって指定されます。複数行のコミットメッセージを入力できます; 大抵のシェルでは行の終わりで引用符を開いたままにするだけで入力できます。

% bzr commit -m "added my first file"

ファイルからメッセージを得るために -F オプションを使うことができます。中には、作業している間にコミットメッセージ用のノートを作り、自分が何を行い何を発言したのか確認するために差分をレビューしたい人がいます。 (このファイルは一休みしてから作業を取り出すのにも役立ちます)

エディタからのメッセージ¶

-m もしくは -F オプションを使わないのであれば、 bzrはメッセージを入力するためにエディタを開きます。起動させるエディタは $VISUAL もしくは $EDITOR 環境変数によって制御され、 ~/.bazaar/bazaar.conf の中の editor 設定によって上書きできます; $BZR_EDITOR は上記で言及したエディタのオプションを上書きします。変更なしでエディタを閉じると、コミットはキャンセルされます。

エディタの中で開かれるファイルは境界線を含みます。この行の下のファイルの部分は情報用のみのために含まれ、コミットメッセージには含まれません。セパレータの下側はコミットで変更されるファイルの一覧が表示されます。上記の行の上側でメッセージを書き、ファイルを保存して閉じます。

編集メッセージとしてコミットする差分を見たければ --show-diff オプションを使うことができます。これはエディタが開くときにエディタの差分を含みます。セパレータの下とファイルに関する情報はコミットされます。これは書いたメッセージを読むことができることを意味しますが、差分自身は終了したときにコミットメッセージに表示されません。一部をメッセージに含めたいのであれば、それらをセパレータの上側にコピー＆ペーストできます。

選択可能なコミット¶

コミットのコマンドラインでファイルもしくはディレクトリの名前を渡すとそれらのファイルへの変更のみがコミットされます。たとえば:

% bzr commit -m "documentation fix" commit.py

デフォルトではサブディレクトリから実行されたとしても bzrは常にツリーへのすべての変更をコミットします。現在のディレクトリのみからコミットするには、ドットを引数として使います:

% bzr commit .

変更に署名をつける¶

たとえば誰かのパッチを適用するときなど、コミットしようとしている変更があなたのものでないなら、 --author という commit のオプションを使って変更に署名をつけられます。

% bzr commit --author "Jane Rey <jrey@example.com>"

ここで指定された人はそのリビジョンの “author” として記録され、あなたはそのリビジョンの “committer” として記録されます。

もしリビジョンの変更がペアプログラミングなどにより複数の人に作られたものならば、 --author を複数回指定して記録することができます。

% bzr commit --author "Jane Rey <jrey@example.com>" \
    --author "John Doe <jdoe@example.com>"

履歴を閲覧する¶

bzr log¶

bzr log コマンドは以前のリビジョンの一覧を表示します。

bzr diff と同じように, bzr log は -r の引数をサポートします:

% bzr log -r 1000..          # リビジョン1000とその後のすべて
% bzr log -r ..1000          # r1000とそれまでのすべて
% bzr log -r 1000..1100      # 1000から1100までの変更
% bzr log -r 1000            # リビジョン1000のみの変更

マージされたリビジョンを見る¶

Bazaarのような分散型のVCSは集中型のVCSツールよりもマージが非常に簡単なので、ブランチの履歴は、メインラインから分離してその後メインラインにマージされるようなラインを含むことがあります。技術的には、無数のリビジョンノード間の関係は無閉路有向グラフ(Directed Acyclic Graph: DAG)として知られます。

多くの場合、まずはメインラインを見てそのあとに別のラインを見たいものです。そのため、log のデフォルトの動作はメインラインを表示して、マージされたリビジョンがあるある場所を指示します。:

bzr log -n0 -rX

全てのリビジョンと全てのマージされたリビジョンを見る場合は:

bzr log -n0

-n オプションは表示するレベルを意味し、0の場合は全てを意味することに注意してください。もしそれがゴミゴミしているなら、値を変更して調整することが容易にできます。たとえば、もしあなたのプロジェクトがトップレベルのgatekeeperがチームレベルのgatekeeperからマージするように構成されている場合、bzr log はトップレベルgatekeeperの履歴だけを表示し、 bzr log -n2 はチームのgatekeeperの履歴を表示します。しかし、ほとんどの場合においては -n0 で十分でしょう。

出力をチューニングする¶

log コマンドは出力を調整するために便利ないくつかのオプションを持ちます。次のものが含まれます:

--forward はログを年代順で表します。

すなわち最新のリビジョンが最後に表示されます。

--limit オプションは表示されるリビジョンの最大数を制御します。

出力の調整方法の詳しい情報に関してはユーザーリファレンスのlogコマンドのオンラインヘルプを参照してください。

ファイルの履歴を閲覧する¶

特定のファイルのみに適用されるように履歴をフィルタリングすることが便利であることがよくあります。これを行うためには、ファイルの名前を log コマンドに提供します:

bzr log foo.py

古いバージョンのファイルを閲覧する¶

指定されたバージョンでファイルの内容を取得するには、次のように cat コマンドを使います:

bzr cat -r X file

X はリビジョンの識別子で file はファイルの名前です。これは出力を標準出力ストリームに送信しますので、次のように閲覧ツール( less や more など)に出力をパイプで渡すかリダイレクトするといいでしょう:

bzr cat -r -2 foo.py | less
bzr cat -r 1 foo.py > /tmp/foo-1st-version.py

グラフィカルな履歴ビューワ¶

履歴のブラウジングはGUIツールが人生を本当に楽にしてくれる領域です。 QBzrとbzr-gtkを含めてこの機能を提供するBazaarのプラグインがたくさんあります。これらがまだインストールされていなければプラグインを利用するで詳細なインストール方法をご覧ください。

QBzrからグラフィカルビューワを使うには:

bzr qlog

bzr-gtkからグラフィカルビューワを使うためには:

bzr viz

viz は実際には visualize の組み込みのエイリアスなので望むのであれば長い方のコマンド名を使います。

プロジェクトをリリースする¶

リリースをパッケージ化する¶

export コマンドはリリースのパッケージを作成するために使われます。すなわち、ブランチの中のファイルとディレクトリをコピーしてそれらを真新しいディレクトリもしくはアーカイブファイルのパッケージを作成します。たとえば、このコマンドは最後にコミットされたバージョンを tar.gz アーカイブファイルにパッケージ化します:

bzr export ../releases/my-stuff-1.5.tar.gz

export コマンドは下記に示されるアーカイブのタイプを作るためにアーカイブファイルの接尾辞を使います。

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

dir (none)

tar .tar

tbz2 .tar.bz2, .tbz2

tgz .tar.gz, .tgz

zip .zip

最新のリビジョン以外のリビジョンをパッケージにすることを望むのであれば、 -r オプションを使います。アーカイブ内部のrootディレクトリを調整したいのであれば、 --root オプションを使います。 export によってサポートされるオプションの詳細についてはオンラインヘルプもしくはユーザーリファレンスを参照してください。

リリースをタギングする¶

リリースのパッケージを作成するために使われたバージョンを覚えるよりも、 tag コマンドを使ってバージョンのためのシンボルを定義する方が便利です:

bzr tag version-1-5

リビジョンの識別子が必要なときはいつでもそのタグを使うことができます:

bzr diff -r tag:version-1-5

ブランチの中で定義したタグの一覧を見たい場合、 tags コマンドを使います。

間違いを取り消す¶

間違いは起きる¶

Bazaarは下記で説明されるような間違いから簡単にリカバーできるように設計されています。

プロジェクトのリビジョンの履歴をドロップする¶

思いがけず間違ったツリーをバージョン管理下に置いたとしても、 .bzr ディレクトリを削除するだけで済みます。

ファイルもしくはディレクトリの登録を解除する¶

バージョン管理下に置きたくないファイルを思いがけず add コマンドで登録しても、それを忘れるようにBazaarにそれを忘れさせるために remove コマンドを使用できます。

remove は修正されたファイルが削除されないよに 安全に物事を行う ために設計されています。たとえば:

bzr add foo.html
(oops - didn't mean that)
bzr remove foo.html

このコマンドは修正されたもしくは未知のファイルについてはエラーを出力します。ファイルを維持したいのであれば、 --keep オプションを使います。代わりに、ファイルを削除したいのであれば、 --force オプションを使います:

bzr add foo.html
(oops - didn't mean that)
bzr remove --keep foo.html
(foo.html はディスクには残るけれども、bzrには登録されない)

一方で、未変更の TODO ファイルは登録が解除されエラー出力なしでディスクから削除されます:

bzr add TODO
bzr commit -m "added TODO"
(hack, hack, hack - but don't change TODO)
bzr remove TODO
(TODO ファイルは削除される)

注: IDEもしくはオペレーティングシステムのファイルマネージャーを利用してファイルを削除する場合、 commit コマンドはそれを削除されるものとして暗黙のうちに扱います。

最後のコミット以降の変更を取り消す¶

バージョン管理ツールを使う理由の1つは作業をしている間にツリーのステータスを楽に調べられることです。最新の commit 以降の変更を廃棄することを決心したら、使うコマンドは revert です:

bzr revert

事前の警告として、実際にすべてが本当に廃棄されたことを確認するために bzr status と bzr diff を最初に使うことはよい習慣です。

最後のコミット以降のファイルへの変更を取り消す¶

最後のコミット以降の特定のファイルの変更を取り消したいが、ツリーの他のすべての変更を維持したい場合、ファイルの名前を引数として revert に渡します:

bzr revert foo.py

最後のコミットを取り消す¶

意図しないコミットをしてしまったら、取り消すために uncommit コマンドを使います:

bzr uncommit

revert とは異なり、 uncommit は作業のツリーの内容をそのままにします。意図せずに間違ったエラーメッセージをコミットしてしまった場合、これは本当に重宝します:

bzr commit -m "Fix bug #11"
(damn - wrong bug number)
bzr uncommit
bzr commit -m "Fix bug #1"

コミットを取り消す別の理由は1つもしくは複数のファイルの追加を忘れたからというものです。これを避けるために、未知のファイルがツリーの中で見つかるとコミットがエラーになるように commit を commit --strict のエイリアスにする人もいます。

注: merge コマンドは次の章まで紹介しませんが、 uncommit で追加するマージをリストアすることは無意味です。 (uncommit の後で bzr status を実行するとこれらが表示されます) merge は履歴の前の方の指定したコミットだけを効率良く取り消すためにも使われます。 merge に関する詳細な情報は次の章の変更をマージするとBazaarのユーザーリファレンスを参照してください。

複数のコミットを取り消す¶

複数のコミットを取り消すためには -r オプションを使います:

bzr uncommit -r -3

これを行うための理由が本当にいくつかの変更を破棄したいのであるなら、 uncommit は作業ツリーを変更しないことを覚えておいてください: タスクを完了させることと同じようにおそらく revert コマンドを実行する必要があります。しかし多くの場合、履歴をそのままにしておき、最新のよい状態の内容を反映する新しいリビジョンを追加する方が間違いなくベターです。

過去のバージョンの状態に戻す¶

望まない変更を行ったが、コードがユーザーに公開されているのでコミットの取り消しが合理的ではない場合、作業ツリーを望む状態に戻すために revert を利用できます:

% bzr commit "Fix bug #5"
Committed revision 20.
(release the code)
(hmm - bad fix)
bzr revert -r 19
bzr commit -m "Backout fix for bug #5"

この作業によってツリー全体をリビジョン19の状態に変更します。それ以降は新しいコミットをしていなければ、おそらくこれがあなたのしたい唯一のことです。新しいコミットをしている場合は、 revert はそれも消してしまいます。その場合は、わるい修正を取り消す代わりにリバースチェリーピックを使う方がよいでしょう。

注: 19のような絶対的なリビジョン番号の代わりに、負の数を使ってチップ(-1)と相対的なリビジョンを指定できます:

bzr revert -r -2

タグを訂正する¶

早まってタグを定義したのなら、 tag コマンドの --force オプションを使って再定義します:

bzr tag 2.0-beta-1
(oops, we're not yet ready for that)
(make more commits to include more fixes)
bzr tag 2.0-beta-1 --force

タグをクリアする¶

タグを定義したが使いたくないのであれば、削除するために、 tag コマンドの --delete オプションを使うことができます:

bzr tag 2.0-beta-4
(oops, we're not releasing a 4th beta)
bzr tag 2.0-beta-4 --delete

同僚と共有する¶

他の人と連携する¶

Peer-to-peerをうまくやる¶

多くの場合、1人よりも2人で考える方がベターです。 1人でプロジェクトを始め、誰かがあなたを手伝いたい、もしくはあなたが別の人に助けを求めたいことがあります。ペアプログラマとしてタスクを割り当てられたより大きなチームのメンバーであることでしょう。どちらにしても、効率よく共同作業を行うために、2人の人間がプロセス、ガイドラインとツールセットの一式に同意する必要があります。

誰かに電話で直接呼び出すことが許可されていなくて、彼らに話しかける唯一の方法は最初に電話会議を予約することである場合を想像してください。集中型のVCSのリポジトリを通してのみコードを共有する企業とコミュニティは毎日そのような拘束に耐えています。中央管理がうまくいくときもあれば、peer-to-peerがうまくいくときもあります。 Bazaarはどちらの場合でも手助けになるように設計されました。

パートナーのワークフロー¶

これは唯一の方法ではありませんが、下記の パートナーのワークフロー はBazaarを利用してペアで共同作業をしたい人々のためのよいスタート地点です。

以前の章でカバーしたタスクに加えて、この章では2つの必要不可欠なコラボレーション活動を紹介します:

ブランチのコピーを手に入れる

複数のブランチの間の変更をマージする

コードベースに取り組むだけのときでも、たとえば異なるリリースのために複数のブランチを手元に置き必要に応じてそれらの変更をマージすることはとても実用的です。あなたの “パートナー” が本当にあなた自身かもしれませんから。

プロジェクトをブランチする¶

ブランチのURL¶

誰かがあなたの作品のコピーを手に入れる前に、転送プロトコルを理解する必要があります。ブランチのトップレベルのディレクトリを、Windowsユーザーが慣れ親しんだ方法で、ネットワーク上で共有することを決定するとします。 LinuxとOS Xのユーザーは、大抵のSSHサーバーに組み込まれているセキュアなプロトコルである、SFTPを通してアクセスする方が望ましいです。 Bazaarは下記で一部が示されるたくさんのプロトコルのサポートに関して とても 柔軟です。

スキーム説明

file:// 標準ファイルシステムを利用してアクセスする (デフォルト)

bzr+ssh:// SSH ごしのアクセス (リモートで最良の選択肢).

sftp:// SFTPを利用してアクセスする (大抵のSSHサーバーはSFTPを提供する)

bzr:// Bazaarのスマートサーバーを利用した高速のアクセス

ftp:// パッシブFTPを利用してアクセスする

http:// Webサーバーによって公開されたブランチへのアクセス

https:// Webサーバーによって公開されたブランチへの、暗号化されたアクセス

上記で示されるように、ブランチは転送プロトコルを示すスキームを伴うURLを使用して識別されます。スキームが無ければ、通常のファイルの名前が想定されます。サポートされるプロトコルの完全なリストに関しては、 urlspec のオンライントピックもしくはBazaarのユーザーリファレンスの URLの識別子のセクションを参照してください。

URL は通常サーバーのルートディレクトリから解決されます。なので、 ftp://example.com/repo/foo はそのホストの /repo/foo ディレクトリを意味しています。(「通常」といっているのは、ApacheのようないくつかのサーバーソフトウェアはURLを任意の場所にリマップできるからです。この場合はサーバーの設定ファイルを確認して、どのURLがどのディレクトリを参照しているかを探さないといけないでしょう)

サーバー上の自分のホームディレクトリからの相対パスを使うには、チルダを使います。たとえば bzr+ssh://example.com/~/public_html と書くと、ホームディレクトリの中の public_html ディレクトリにマップされます。

Note

HTTP や HTTPS ごしのアクセスはデフォルトでは読み込み専用です。読み書き両方に対応するための設定については、 HTTP スマートサーバーごしの push を参照してください。

共用レポジトリに関するリマインダ¶

ブランチのコピーを手に入れる前に、ファイルシステム上に設置する場所を少し考えてみましょう。最大限のストレージの効率性のために、共用リポジトリとしてセットアップされたディレクトリの元でブランチを作ることを推奨します。 (よく使われるレイアウトについては、作業スペースを構成するの中のブランチの機能を参照してください) たとえば:

bzr init-repo my-repo
cd my-repo

誰からでもブランチを入手して好きなようにする準備ができました。

ブランチのコマンド¶

既存のブランチに基づいたブランチを手に入れるためには、 branch コマンドを使用してください。構文は次のとおりです:

bzr branch URL [directory]

ディレクトリの名前が渡されない場合、URLの最後の部分に基づいてディレクトリが作成されます。ドライブ名 (M:/) とSFTPのURLを示すそれぞれの例は次のとおりです:

bzr branch M:/cool-trunk
bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk

新しいブランチを使うために明示的にディレクトリの名前を渡す例は次のとおりです:

bzr branch /home/mary/cool-repo/cool-trunk cool

時間とスペースへの考慮¶

転送されるブランチのサイズとコンピュータとソースのブランチの間のネットワーク帯域とレイテンシによっては、この初期の転送は少し時間がかかります。その後の更新は変更のみが転送されるので遙かに速くなります。

Bazaarは最新のスナップショットではなくブランチの完全な履歴を転送することを覚えておいてください。結果として、 branch を完了させた後でネットワークから離脱しても、ブランチの履歴に対して log と diff を好きなだけ行うことができます。さらに、履歴がローカルで保存されているのでこれらのオペレーションは速いです。

Bazaarはバージョンの履歴を保存するために求められるディスクスペースの総量を最小限にするスマートな圧縮技術を使うことに注意してください。多くの場合、プロジェクトの完全な履歴は最新バージョンの作業コピーよりも少ないディスクスペースを占めます。

後の章で説明するように、Bazaarはブランチの軽量チェックアウト、すなわち履歴のローカルなストレージなしの作業ツリーもサポートします。もちろん、接続しない使い方は利用できませんが、ローカルディスクスペースが本当に厳しいのであればそれはあなたが決めることができるトレードオフです。現在、制限された履歴の振り返りのためのサポート - 履歴の水平線(history horizon) - は開発段階にあります。

ブランチの情報を閲覧する¶

配布元も含むブランチの情報を見たいのであれば、 info コマンドを使います:

bzr info cool

ブランチが引数として渡されなければ、現在のブランチの情報が表示されます。

変更をマージする¶

並行開発¶

誰かがプロジェクトの独自ブランチを持ったら、並行して変更を行い、オリジナルのブランチを続ける開発にコミットできます。まもなくですが、開発の独立したラインを結合することが必要にあります。このプロセスは マージ (merging) として知られます。

mergeコマンド¶

別のブランチから変更を受け入れるためには、 merge コマンドを使います。構文は次のとおりです:

bzr merge [URL]

URLが渡されない場合、オリジナルのものから由来する初期のブランチがデフォルトとして使われます。たとえば、BillがMaryの作業内容からブランチを作る場合、下記のようにコマンドを入力すれば彼女の次の変更をマージできます:

bzr merge

一方で、MaryはBillのブランチで行われた作業内容を彼女のブランチにマージしたいかもしれません。この場合、彼女は最初に明示的にURLを渡す必要があります:

bzr merge bzr+ssh://mary@bill-laptop/cool-repo/cool-trunk

マージブランチがまだ設定されていなければ、これによってデフォルトのマージブランチが設定されます。設定した後でデフォルトを変更するためには、 --remember オプションを使います。

マージの動作方法は？¶

マージのためのいくつかのアルゴリズムがあります。 Bazaarのデフォルトのアルゴリズムは次のように動作する 3方向マージ (3-way merging) の一種です。 Aが祖先でBとCの2つがブランチであると仮定すると、次のテーブルは使われるルールを提示します。

A B C 結果コメント

x x x x unchanged

x x y y line from C

x y x y line from B

x y z ? conflict

マージの中には人間の手助けによってのみ完了するものがあることに留意してください。これらを解決する方法の詳細は衝突を解消するを参照してください。

マージを記録する¶

衝突が解決した後で、マージをコミットする必要があります。例です:

bzr commit -m "Merged Mary's changes"

衝突が無くても、明確なコミットがまだ必要です。他のツールとは異なり、これはBazaarの機能と考えられています。クリーンなマージは必ずしもよいマージとは限らないので、個別の明確なステップとしてコミットすることで、すべてがよい状態にあることを検証するための最初のテストスィートを実行できます。

問題が見つかったら、マージをコミットする前にそれらを訂正するもしくは revert を使用してマージを廃棄すべきです。

マージの追跡¶

Bazaarの機能の中で最も重要な機能の1つは、分散型で高品質のマージトラッキング です。言い換えると、Bazaarは何がすでにマージされていることを覚えており、マージのための最良の祖先を賢く選ぶためにその情報を使い、衝突の回数と規模を最小にします。

あなたが他の多くのVCSツールの難民であるなら、 何が何でもマージは避けさせてください という習慣から抜け出すのは本当に難しいかもしれません。 Bazaarによっていつでも安全に他の人とのマージを行うことができます。 peer-to-peerの方法でうまくゆくときに、高い品質を保つために、 “統合のたまり場”として集中型のブランチを使うことも避けられます。コラボレーションしている変更を本当に広く共有する準備ができたら、変更を中心のブランチにマージしてコミットする機会です。

このようにマージ機能がうまくゆけば開発者の共同作業の方法を変えることができます。

衝突の解消¶

ワークフロー¶

マージプロセスの間にそれぞれの衝突を解消することを強制する他のいくつかのツールとは異なり、Bazaarはできる限りマージしてから衝突を報告します。これによって衝突の解消をより扱いやすくします。解消すべき方法を決めることを手助けするためにポストマージツリー全体の内容が利用可能だからです。それぞれの解消もしくはグループがよい状態であることを確認するためにテストをいくつか選んで実行することもよいでしょう。

衝突の一覧を表示する¶

merge コマンドで報告されるのと同様に、突出した衝突の一覧は conflicts コマンドを使用することでいつでも表示されます。これは status コマンドから出力の一部として含めることも可能です。

衝突を解消する¶

衝突に遭遇したら、 merge コマンドは解決されていない領域を表示する埋め込みマーカーをそれぞれのファイルに追加します。 1つの衝突を持つそれぞれのファイルに対して3つのファイルも作ります:

foo.BASE

foo.THIS

foo.OTHER

foo は衝突したファイルの名前です。多くの場合、問題になっているそれぞれのファイルを手作業で編集し、関連領域を修正し衝突マーカーを除去することで衝突を解消できます。

衝突の中のすべてのファイルを修正し、マーカーを削除した後で、 resolve コマンドを使用してBazaarにそれらを解決したものとしてマークするように頼みます:

bzr resolve

代わりに、それぞれのファイルを修正した後で、これを解消したものとしてマークできます:

bzr resolve foo

resolve コマンドは作業ツリーからBASE, THIS, OTHERファイルをクリーンナップします。

remergeコマンドを使う¶

いくつかの場合、任意のファイルに対して異なるマージアルゴリズムを試したいことがあります。これを行うためには、ファイルを次のように指定して remerge コマンドを使います:

bzr remerge --weave foo

foo はファイルで weave オプションは利用可能なマージアルゴリズムです。いわゆる criss-cross (十字遺伝)マージが検出されたときに、たとえば、2つのブランチが同じものをマージしてからお互いをマージするときに、このアルゴリズムはとりわけ便利です。詳細については criss-cross と remerge のオンラインヘルプを参照してください。

衝突を解消するために外部ツールを利用する¶

衝突を解消するためにGUIツールを利用したいのであれば、 extmerge プラグインをインストールしてください。次のようにインストールできます:

bzr extmerge foo

foo は衝突したファイルです。解消するファイルの一覧を提供するよりも、すべての衝突ファイルを暗黙の内に指定するために --all オプションを利用できます。

extmerge コマンドは bazaar.conf ファイルの中の external_merge 設定によって指定されるツールを使います。設定されていなければ、 kdiff3 もしくは opendiff のような人気のあるマージツールが設定されます。後者はOS XのFileMergeのコマンドラインインターフェイスです。

変更に注釈を付ける¶

内容の起源を探し出す¶

複数の人がファイルに取り組むとき、誰が作ったのかもしくは最後に変更された内容を一度に見ることができるのは非常に便利です。これを行うためには、annotateコマンドを使います:

bzr annotate readme.txt

悲観主義者もしくは楽観主義者のどちらかであるなら、 annotate の組み込みのエイリアスである blame もしくは praise を使うことを好むかもしれません。どの方法であれ、次のような情報と一緒にファイルのそれぞれの行が表示されます:

最後に変更した人

最後に変更した時間

コミットメッセージ

GUIツール¶

Bazaar用のさまざまなGUIは注釈の情報を閲覧するためのグラフィカルなツールを提供します。たとえば、bzr-gtkプラグインはこの機能を gannotate コマンドを使用して起動できるGUIツールとして提供します:

bzr gannotate readme.txt

GUIツールは関心のある情報をより豊かに表現するので (たとえばそれぞれのコミットのすべての変更内容)、テキストベースよりも好ましいかもしれません。

集中スタイルの、チームコラボレーション¶

集中型の開発¶

動機¶

並行して作業をして時折マージするよりも、ロックステップ、すなわち複数の人が継続して変更を中心位置にコミットしてすべてのコミットの前に彼らの作業内容を最新の内容にマージすること、で一度に作業をすることは有用であることがあります。

このワークフローはSubversionとCVSのような集中型のVCSツールのユーザーにはとても慣れ親しまれています。単独の開発者が複数のマシンに取り組む場合にも応用できます。たとえば、通常はデスクトップで作業をするが旅行の間はラップトップ、もしくは(インターネットに接続した)ホームコンピュータで勤務時間外に事務作業を完了させるといった具合です。

あなたのチームがすでに集中型の開発でうまくいっているのであれば、それは素晴らしいことです。多くのチームはこの方法でBazaarを使い始め、後で代替のワークフローを実験します。

集中型のワークフロー¶

下記のダイアグラムは 集中型のワークフロー の概要を提供します。

あなたのチームがより分散型のワークフローを利用することを計画しているとしても、この章でカバーされる多くのタスクは、とりわけブランチを公開する方法に関してあなたにとって有用です。

ブランチを公開する¶

集中型リポジトリをセットアップする¶

集中型のワークフローはコンピュータ上のブランチを中心型のブランチとして指名することで使うことができます。実際大抵のチームは集中型のブランチをホストするために専用サーバーを持ちます。

共用リポジトリをローカルで使うことが最良の習慣であるように、中心型のブランチを共用リポジトリを設置することもお勧めです。通常は、中心型の共用ブランチはファイルの作業コピーではなく履歴のみを保存することに注意してください。なので、そのような共有リポジトリを作るときには通常 no-trees オプションを使います:

bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/PROJECT

この手順をcvsrootもしくはSubversionのリポジトリのセットアップとして似たようなものとして考えることができます。しかしながら、Bazaarはリポジトリ内のブランチの編成方法をより柔軟にします。ガイドラインと例に関しては付録の共用レポジトリのレイアウトを参照してください。

集中型ブランチを始める¶

集中型ブランチに初期の内容を投入する方法は2つあります:

ローカルのブランチを作り中央にプッシュする

空の中央ブランチを作り内容をコミットする

最初のやり方の例です:

bzr init-repo PROJECT  (ローカルリポジトリを準備する)
bzr init PROJECT/trunk
cd PROJECT/trunk
                       (開発ファイルをコピーする)
cp -ar ~/PROJECT .     (OS固有のツールを使用してファイルをコピーする)
bzr add                (リポジトリを投入する; バージョン管理を始める)
bzr commit -m "Initial import"
                       (中心リポジトリに公開する)
bzr push bzr+ssh://centralhost/srv/bzr/PROJECT/trunk

2番目のやり方の例です:

bzr init-repo PROJECT  (ローカルリポジトリを準備する)
cd PROJECT
bzr init bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
bzr checkout bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
cd trunk
cp -ar ~/PROJECT .     (OS固有のツールを使用してファイルをコピーする)
bzr add                (リポジトリを投入する; バージョン管理を始める)
bzr commit -m "Initial import"
                       (中心リポジトリに公開する)

checkout コミットを使って作られた作業ツリー内部でコミットするとローカルと同様に内容は暗黙の内に中心位置にコミットされることに注意してください。 checkout の代わりに branch コマンドを使ったので、内容はローカルにのみコミットされます。

このように中心位置に密接に連動した作業ツリーは チェックアウト(checkouts) と呼ばれます。この章の残りでは数多くの機能を詳しく説明します。

チェックアウト機能を利用する¶

ブランチをチェックアウトに変更する¶

ローカルのブランチを作りチェックアウトに変更したいのであれば、 bind コマンドを使います:

bzr bind bzr+ssh://centralhost/srv/bzr/PROJECT/trunk

たとえば以前のセクションで説明されたように push を使って集中型のブランチを作った後でこれは必要です。

これをした後は、コミットはローカルに適用される前にバインドしたブランチに適用されます。

チェックアウトをブランチに変更する¶

チェックアウトを通常のブランチに変更したい場合、 unbind コマンドを使います:

bzr unbind

この後で、コミットはローカルのみに適用されます。

チェックアウトを入手する¶

集中型のブランチを利用してチームで作業するとき、1人の人物が以前のセクションで示される初期の内容を提供する必要があります。その後は、それぞれの個人がローカルのチェックアウト、すなわち彼らが変更を行うサンドボックス、を作るために checkout コマンドを使用します。

SubversionとCVSと異なり、Bazaarでは checkout コマンドは最新の内容を保持している作業ツリーを作るのに加えて履歴のローカルな全コピーを作ります。 diff や log といったオペレーションは速く中心位置から接続していないときも利用できることを意味します。

軽量チェックアウトを入手する¶

Bazaarはバージョン履歴を効率的に保存するために役立つ一方で、履歴が望まれていないときがあります。たとえば、チームがBazaarを利用して集中型でウェブサイトの内容を管理している場合、公開ウェブサーバー上の内容のチェックアウトを更新するのと同じぐらいリリースプロセスは単純です。この場合、次の理由からその場所にダウンロードする履歴は望まないでしょう:

必要のない履歴を保有することでディスクスペースを無駄遣いする

秘密を維持したいBazaarブランチを公開する

Bazaarで履歴のないチェックアウトを入手するには、 --lightweight オプションを使います:

bzr checkout --lightweight bzr+ssh://centralhost/srv/bzr/PROJECT/trunk

もちろん、これによって通常のチェックアウトの多くの利点は失われますが、役に立つ場合と時を選ぶトレードオフです。 --lightweight オプションは、すべてのブランチではなくチェックアウトのみに適用されます。

注: コードベースが実際に大きくコンピュータ上のディスクスペースが限られている場合、共用リポジトリ, スタックブランチ, チェックアウトを再利用するを含めたすべてのオプションを必ず考えてください。

コミットの失敗を扱う¶

commit を実行する前にチェックアウトを最新にしなければならないことに注意してください。 Bazaarはこの点でSubversionもしくはCVSよりも厳密です - 変更したファイルだけでなくすべてのツリーを最新にする必要があります。 Bazaarはあなたが最後に更新した後で中心位置にリビジョンが追加されたことを検出すると update を実行するようにあなたに頼みます。

バインドされたブランチへのネットワーク接続が失われると、コミットは失敗します。いくつかの代替の次善策は次のセクションで説明します。

オフラインで集中型のブランチに取り組む¶

集中型のローカルコミットのワークフロー¶

旅行のためネットワーク接続できない場合、中心サーバーがダウンする、もしくは今は中心位置に公開せずにローカルで変更のスナップショットを記録したいだけなら、このワークフローはそんなあなたのためにあります。

ローカルでコミットする¶

チェックアウトで作業していてローカルだけでコミットする必要がある/したい場合、 --local オプションを commit コマンドに追加します:

bzr commit --local

長期間切断する¶

しばらくの間バインドされたブランチから切断をする予定もしくはしたい場合、 --local をすべての commit コマンドを追加することを覚えるのは面倒でしょう。代わりの方法はチェックアウトを一時的に通常のブランチにするために unbind コマンドを用い、後でロックステップの状態に戻りたくなったときに bind コマンドを使うことです。

bind コマンドはこのブランチがチェックアウトされた最後の時間が結びつけられた場所を覚えるので、前の unbind の後で bind を使うときにリモートブランチのURLを入力する必要がないことに留意してください。

ローカルコミットのシリーズをマージする¶

中心ブランチ上で進行中の開発から独立してローカルでコミットするとき、次回 update が実行されるときBazaarはこれらを開発の2つのラインとして扱います。この場合、 update は次のことを行います:

これはバインドされたブランチからの最新のリビジョンを取り込み、チェックアウトをメインラインの状態にします。

これは最後に更新した以降のローカルな変更を論理的に並行ブランチに移動します

これらを一緒にマージするのでローカルの変更は status によって未解決マージとして報告されます

常に、この後で作業内容を中心ブランチに送信するためには commit を実行する必要があります。

チェックアウトを再利用する¶

動機¶

時々、複数のブランチに取り組むために単独のチェックアウトをサンドボックスとして持つことは便利です。挙げられる理由のいくつかは次の内容を含みます:

作業ツリーが大きいときディスクスペースを節約する

固定された位置で開発する

多くの場合、作業ツリーのディスクの利用量は .bzr ディレクトリよりも大きくなります。複数のブランチに取り組みたいが、それぞれの作業ツリーすべてのオーバーヘッドを許容できない場合、複数のブランチをまたがってチェックアウトを再利用することがうまくゆく方法です。

他の機会において、サンドボックスの位置は数多くの開発とテストツールに設定されます。繰り返しますが、複数のブランチをまたがったチェックアウトの再利用は役に立ちます。

ブランチが結びつけられた場所を変更する¶

チェックアウトが結びつけられている場所を変更するためには、次の手順に従います:

作業内容が失われないようにローカルの変更が中央ブランチにコミットされたことを確認します

取り組みたい新しいリモートブランチのURLを渡して bind コマンドを使います

revert コマンドの後に続いて update コマンドを使用して望むブランチのコピーをチェックアウトします

新しいブランチに bind して update するだけだと、コミットしたもの、していないもの両方のローカルの変更がマージされることに注意してください。 revert か commit を使って、それらを維持するか破棄するかを決めなければいけません。

bind+update レシピの代わりは switch コマンドを使うことです。これは基本的に、ツリーの中のコミットされていない変更がマージされること以外は、既存のブランチを除去して新しい位置で checkout を再び実行することと同じです。

注: 場合によってバインドされた異なるブランチの適切なキャッシュをチェックアウトするために switch はコミットされた変更を廃棄するので、ローカルにコミットされているが最も最近バインドされたブランチにまだコミットされていない変更が存在する場合意図的に失敗します。これらの変更を本当に廃棄したいのであれば、 --force オプションを使います。

軽量型チェックアウトを切り替える¶

軽量型チェックアウトでは、ローカルのコミットは存在せず、 switch は作業ツリーが関連づけられたブランチを効率よく選びます。 1つの可能なセットアップ方法は、ローカルツリーなしのリポジトリと軽量チェックアウトを組み合わせて使うことです。これによって取り組むものを簡単に切り替えることができます。例です:

bzr init-repo --no-trees PROJECT
cd PROJECT
bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
bzr checkout --lightweight trunk my-sandbox
cd my-sandbox
(hack away)

この例のこの範囲でtrunk .bzr ディレクトリを持ちますがそこでのブランチとしての作業ツリーはツリーなしのリポジトリで作られたことに注意してください。必要な数だけブランチを入手もしくは作成して必要に応じてそれらの間で切り替えることができます。例です:

(my-sandboxの中にいることを前提とする)
bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/PROJECT-1.0 ../PROJECT-1.0
bzr switch ../PROJECT-1.0
(fix bug in 1.0)
bzr commit -m "blah, blah blah"
bzr switch ../trunk
(go back to working on the trunk)

注: ブランチはローカルのみのものでも、(checkout で作るか branch でそれらを作った後で bind を使うことで)リモートのブランチにバインドされたものでも可能です。

分散スタイルの、チームコラボレーション¶

分散型の開発¶

動機¶

分散型のVCSツールは共同作業の新しい方法を提供します。これは私達が生きる現代の世界をより反映したものでより高い品質の成果を可能にします。

分散型の共用のメインラインのワークフロー¶

このワークフローにおいて、それぞれの開発者は1つもしくは複数の独自のブランチに加えて、メインブランチのチェックアウトを持ちます。開発者は個人のブランチに取り組み、準備ができたら、それをメインラインにマージします。

他の分散型のワークフローはこの章の後ろの方で検討します。

ブランチを編成する¶

ミラーブランチ¶

開発をするために分散型のワークフローを利用する際の主要な違いはメインのローカルブランチは変更を行う場所ではないことです。代わりに、中心ブランチのそのままのコピーとして保存されます。すなわち、これは ミラーブランチ です。

ミラーブランチを作るためには、共用リポジトリ(まだなければ)を作りミラーを作るために branch コマンド(もしくは checkout)を使います。例です:

bzr init-repo PROJECT
cd PROJECT
bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk

タスクのブランチ¶

それぞれの新しい機能もしくは修正は独自のブランチの中で開発されます。これらのブランチは 機能ブランチ もしくは タスクブランチ として言及されます - 用語はお互いに置き換えて使うことができます。

タスクブランチを作るためには、ミラーブランチに対して branch コマンドを使います。例です:

bzr branch trunk fix-123
cd fix-123
(hack, hack, hack)

この方法には数多くの利点があります:

並行して複数の変更に取り組むことができます

変更の間の交換が減ります

複数の人々は準備ができるまでpeer-to-peerモードでブランチに取り組むことができます

とりわけ、変更が他のものより料理するのに時間がかかるのであれば、レビューを求めたり、フィードバックを適用することができます。中心ブランチにマージする前に個別のブランチで十分な品質の作業を完了させることで、中心ブランチの品質と安定性は以前よりも高い水準を維持します。

ミラーブランチをリフレッシュする¶

これを行うためには pull コマンドを使います:

cd trunk
bzr pull

機能をトランクにマージする¶

異なる分散型のワークフローの方針は変わります、すべての開発者がメイントランクにコミットする権限を持つ最もシンプルな事例は下記のとおりです。

ミラーがチェックアウトなら:

cd trunk
bzr update
bzr merge ../fix-123
(resolve any conflicts)
bzr commit -m "Fixed bug #123"

ミラーがブランチの場合:

cd trunk
bzr pull
bzr merge ../fix-123
(resolve any conflicts)
bzr commit -m "Fixed bug #123"
bzr push

タスクブランチをバックアップする¶

集中型ワークフローの副作用の1つは変更がITオペレーションの一部としてバックアップされる中心位置にしょっちゅうコミットされることです。タスクブランチを開発するとき、作業内容を中心位置に公開することはバックアップになるのでよい考えです(しかし共用位置であることは必須ではありません)。この目的のためだけにローカルのタスクブランチをバックアップサーバー上で確立されたリモートブランチにバインドするとよいかもしれません。

ゲートキーパーを利用する¶

分散型の人間のゲートキーパーのワークフロー¶

このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへのコミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。すべての開発者はタスクブランチの中で変更を行います。

開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更をレビューして受け入れ可能であればマージするよう頼みます。変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチでさらなる開発が進みます。

このアプローチの主要な面は含まれる制御の反転です: 開発者は変更を中心ブランチに”コミット/プッシュ”するときを決めなくて済みます: コードベースはゲートキーパーの “マージ/プル” による統制された変更方法によって発展します。複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、よく採用されている方法です。。たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって通知されます。

このワークフローのすばらしい点の一つはスケーラブルであることです。大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される ローカルマスターブランチ を持つことができます。チームリーダーがリクエストするときにチームのマスターブランチからの変更をプライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。

分散型の自動ゲートキーパーのワークフロー¶

より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。

PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。

変更を送信する¶

動機¶

多くの分散型のシナリオでは、開発者にとってURLを公開することでタスクブランチを共有することが常に現実的であるとは限りません。たとえば、開発者が在宅で一晩中作業をする場合、ゲートキーパーが別のタイムゾーンでレビューしてマージしたいときに開発者はタスクブランチに十分にアクセスできません。

Bazaarは手助けする巧妙な機能: マージディレクティブ を提供します。

マージのディレクティブを理解する¶

マージディレクティブを”ミニブランチ” - ブランチが作成された後の成長部分 - として考えることができます。これは変更点を記したソフトウェアパッチですが、追加情報として中間コミット、リネームとデジタル署名のようなメタデータがつきます。

別の実用的なメタファはパケットケーキ: レシピと必要な材料を持ったマージディレクティブです。具体的にいえば、材料とはブランチ上で加えられた全ての変更のメタデータで、レシピとはそれらの変更点をどうやってマージするかで、 merge コマンドが共通の祖先を選ぶのに利用する情報です。

それらをどのように考えるのであれ、マージディレクティブはよいものです。これらは簡単に作れて、メールに添付して送信するのに最適で、受け取った後でブランチと同じように処理できます。

マージディレクティブを作る¶

マージディレクトリを作りオプションとして送信するためには、 send コマンドを使います。

デフォルトでは、 send はマージディレクティブをブランチのための “投稿アドレス” 、通常はリード開発者もしくは開発メーリングリストにEメールを送信します。オプションなしの send はマージディレクティブを作り、Eメールツールを作動させて添付し、少しの説明文を追加するための準備をします。 (この設定方法の詳細に関してはオンラインヘルプの send とリファレンスマニュアルの構成設定を参照)

大抵のプロジェクトではパッチ付きのメールに説明文を追加し、パッチの理由と内容を説明します。これによってレビューワは行単位の差分に入る前にいくらかの事情を理解できます。

代わりに、 --output (or -o) オプションが渡されると、 send はマージディレクティブをファイルに書くので、あなた自身にメールを送り、それを検査し、後の使用のために保存できます。 - の出力ファイルが渡されると、ディレクティブはstdoutに書き込まれます。例です:

cd X-fix-123
bzr send -o ../fix-123.patch

マージのディレクティブを適用する¶

merge と pull コマンドを使うことでマージディレクティブはブランチと同じ方法で適用できます

これらはBazaarを使わない上流のプロジェクトとコミュニケーションをするときにも便利です。とりわけ、マージディレクティブ内の変更全体のプレビューは無地のソフトウェアパッチのようになるので、たとえば彼らは patch -p0 を使用してそれらを適用できます。

その他のトピック¶

これからの長い旅¶

前の章でBazaarがあなた自身と他の人との共同作業を生産的にすることを手助けしてくれる方法について確固として理解して頂けることを筆者達は願っております。初めてBazaarを学んでいるのであれば、一度習得したら、このマニュアルに戻るためにすでにカバーされた手順を試すとよいかもしれません。

残りの章ではBazaarをより適切に使うためのさまざまなトピックをカバーしています。明言されない限り、この章と残りの章はそれぞれ独立しているので好きな順序で読むことができます。

疑似マージ¶

チェリーピッキング¶

時々、ブランチの変更の全部ではなく一部だけを選んでマージすることが便利であることがあります。これは一般的に チェリーピッキング(cherrypicking) として言及されます。

チェリーピッキングが役に立ついくつかの事例:

メインの開発ブランチから修正の一部を取り出してリリースブランチに取り込む
実験ブランチから改善内容を選別して機能ブランチに取り込む

foo ブランチのリビジョン Xによってなされた変更のみをマージするためには:

bzr merge -c X foo

foo ブランチのリビジョンXまでの変更のみをマージするためには:

bzr merge -r X foo

foo のリビジョンX以降の変更のみをマージするためには:

bzr merge -r X.. foo

foo ブランチのリビジョンXからリビジョンYまでの変更のみをマージするには:

bzr merge -r X..Y foo

通常のマージと同じように、チェリーピックは明示的にコミットしなければなりません。これを行う前に、 bzr diff を利用した変更を見て何かあればテストスイートを実行するとよいでしょう。

通常のマージとは異なり、Bazaarは現在はチェリーピックを追跡しません。具体的に言うと、変更は通常のコミットと同じようになり、他のブランチから来た(内部の)変更履歴は失われます。上記のようなチェリーピックが役に立つ場面では、このことはたいてい重大な問題ではありません。フルマージが後で行われることはけっしてないと言える十分な理由があるからです。そうではない場面では、変更が再びマージされたときにまた衝突を解消する必要があります。

親のないマージ¶

チェリーピックに関連したテクニックとして、マージ元のリビジョンを参照せずに、コミット前に親リビジョンを忘れることができます。こうすると、このマージで行われた全ての変更が、1回のコミットで行われたような効果があります。マージしたあと、コミットする前に次のコマンドを実行します。

bzr revert --forget-merges

これで、作業ツリー内の変更は残したまま、その変更がどこからマージされたかの記録だけを削除します。そして、次のコミットではマージされたリビジョンに関する情報が一切ない状態で、全ての変更を記録します。

この機能は、「きれいな」履歴を作りたいユーザーに取って便利なものですが、 Bazaarはもともとマージされた履歴を段階的に表示する機能を持っているので、失った履歴の価値が履歴のきれいさの価値を上回らないように気をつける必要があります。特に、この機能を使うとマージ元の変更だけを取り込んでその変更のマージ元を記録しないので、後で同じマージ元からマージしようとすると余計なコンフリクトを発生させる可能性があります。

リバースチェリーピッキング¶

チェリーピッキングは一連の変更を元に戻すことができます。この場合、リビジョン範囲の上界(upper bound)が下界(lower bound)よりも 小さく なります。たとえば、リビジョン10の変更を取り消すためのコマンドはこうなります:

bzr merge -r 10..9

どこかから、すべてではない大半の変更を得たい場合通常のマージをした後に少しのリバースチェリーピックを行うとよいでしょう。

コミットされていない変更をマージする¶

複数のブランチを持っており、間違えて別のブランチを変更し始めた場合、訂正をとるステップは次のとおりです。ブランチ bar で作業したかったのに、ブランチ foo で作業を始めてしまったという場合を前提とします:

bar ブランチに移動する
bzr merge --uncommitted foo を実行する
やってくる変更をチェックする (bzr diff)
foo ブランチに変更する
bzr revert を実行する

リベースする¶

通常のマージの別のオプションは リベース(rebase) です。すなわち、現在のブランチが本来とは異なる地点をベースにするようにします。リベースは rebase プラグインによって提供される rebase コマンドによってサポートされます。

rebase コマンドは現在の作業ディレクトリ内のリベースされるブランチ上で別のブランチの位置をとります。ブランチが指定されないと親のブランチが使われ、通常これは望まれる結果です。

最初のステップは現在のブランチのものであるが親のブランチではないリビジョンを特定することです。現在のブランチはターゲットブランチと同じリビジョンに設定され、それぞれのリビジョンはブランチのトップで再現されます。プロセスの終了時に現在のブランチがターゲットの最終リビジョンからブランチされたようになります。

再現されるそれぞれのリビジョンがツリーの中で衝突を起こすことがあります。これが起きたらコマンドは停止してそれらを修正しなければなりません。 merge するためにコミットを解消し、それらが解消されたものとしてマークするために bzr resolve を実行します。すべての衝突を解消したら、リベースオペレーションを続けるために bzr rebase-continue を実行します。衝突に遭遇せず続けないことを決めたら、 bzr rebase-abort を実行できます。リプレイされるコミットの一覧を表示するために rebase-todo を利用することもできます。

注: マージトラッキング機能が貧弱なVCSツールから来たユーザーの中にはリベースを好む人がいます。古いツールでの作業方法に似ている、もしくは”完璧にきれいな” 履歴が重要だからです。 Bazaarでリベースする前に、通常のマージがベターな選択肢ではないのか考えてください。とりわけ、始める前にプライベートなブランチをリベースするのは大丈夫ですが、他の誰かとブランチを共有した後のリベースは 強く非推奨 です。

Shelving Changes¶

ときどき、作業ツリーから一時的に変更点を取り除いて、あとで元に戻したいことがあるかもしれません。たとえば何か作業中に小さいバグフィックスを見つけてコミットする場合などです。 Bazaarは変更を shelf (書棚)に保存する機能を持っています。後で変更を元に戻したくなったときは、 unshelve を使って作業ツリーに戻すことができます。

たとえば、一つか複数の変更がされた作業ツリーを考えて見ます…:

$ bzr diff
=== modified file 'description.txt'
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
 ===============

 These plugins
-by Michael Ellerman
+written by Michael Ellerman
 provide a very
 fine-grained 'undo'
 facility
@@ -11,6 +11,6 @@
 This allows you to
 undo some of
 your changes,
-commit, and get
+perform a commit, and get
 back to where you
 were before.

shelve コマンドはインタラクティブにどの変更を作業ツリーに保留しておきたいのかを質問します。:

$ bzr shelve
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
 ===============

 These plugins
-by Michael Ellerman
+written by Michael Ellerman
 provide a very
 fine-grained 'undo'
 facility

Shelve? [yNfrq?]: y
--- description.txt
+++ description.txt
@@ -11,6 +11,6 @@
 This allows you to
 undo some of
 your changes,
-commit, and get
+perform a commit, and get
 back to where you
 were before.

Shelve? [yNfrq?]: n
Shelve 2 change(s)? [yNfrq?]', 'y'
Selected changes:
 M  description.txt
Changes shelved with id "1".

もしたくさんの変更が作業ツリーにあるのであれば、 shelve コマンドにファイルのリストを渡して、それらのファイルの変更だけについて質問されるようにすることができます。変更を shelve した後に diff コマンドで作業ツリーに期待する変更だけが残っていることを確認するとよいでしょう。:

$ bzr diff
=== modified file 'description.txt'
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
 ===============

 These plugins
-by Michael Ellerman
+written by Michael Ellerman
 provide a very
 fine-grained 'undo'
 facility

よし! - コミットする準備ができました:

$ bzr commit -m "improve first sentence"

後になって、shelveした変更を作業ツリーに unshelve コマンドで戻します:

$ bzr unshelve
Unshelving changes with id "1".
 M  description.txt
All changes applied successfully.

もし望むのであれば、複数のアイテムをshelfに置くことができます。通常 unshelve が実行されるたびに最も最近 shelve された変更が元に戻されます。明示的にどの変更を戻すのかを指定することで別の順序で unshelve することもできます。

Bazaarはshelveされた後に変更があっても、shelfの変更を作業ツリーにマージするので、衝突が発生するかもしれません。その場合は通常のマージ後と同じように衝突を解決しなければなりません。

Filtered views¶

Filtered view の紹介¶

Viewはtreeに対するマスクを提供し、ユーザーはtreeの一部分に集中できるようになります。このマスキングが役に立ついくつかの場面があります。たとえば、大きなプロジェクトの技術ライターやテスターはプロジェクトのうち一部のディレクトリやファイルだけを扱います。

開発者は大規模な変更をviewを使っていくつかのコミットに分解したいと思うかもしれません。 shelve unshelve がいくつかの変更を後のコミットまでとっておくのに対して、viewは次のコミットに(何を含めないかではなく)何を含めるかを指定します。

viewを作った後は、ファイルリストをサポートするコマンド - status, diff, commit, etc - に暗黙的に毎回そのファイルリストが渡されます。それらのコマンドに明示的にファイルリストを渡すことも可能ですが、指名するファイルは現在のviewの中にないといけません。対照的に、ツリーを対象とするコマンド - pull, merge, update, etc - はviewが作られた後もツリー全体に対して操作しますが、現在のviewに関係するもののみを報告します。どちらのケースでも、Bazaarはユーザーに毎回viewが使われていることを報告するので、操作や出力がマスクされていることが判ります。

ノート: filtered view は 2a フォーマット(Bazaar 2.0 以降でデフォルトのフォーマット)でのみ有効です。

view を作る¶

次のように, view コマンドにファイルやディレクトリを指定することでviewを作ります:

bzr view file1 file2 dir1 ...

出力は:

Using 'my' view: file1, file2, dir1

現在のviewをリストする¶

現在のviewを見るには、 view コマンドに引数をつけないで実行します:

bzr view

もしviewが無ければ、 No current view. というメッセージが出力されるでしょう。そうでなければ、現在のviewの名前と内容が次のように表示されます:

'my' view is: a, b, c

viewを切り替える¶

ほとんどの場合、viewは「変更を選択するために作られて、変更がコミットされると削除される」という具合に短い期間で使われます。それ以外の場合では、viewに名前をつけてそれを切り替えたい場合があるかもしれません。

名前つきviewを宣言してそれに切り替えるには:

bzr view --name view-name file1 dir1 ...

たとえば:

bzr view --name doc NEWS doc/
Using doc view: NEWS, doc/

名前つきviewを見るには:

bzr view --name view-name

名前つきviewに切り替えるには:

bzr view --switch view-name

全ての名前つきviewの一覧を得るには:

bzr view --all

一時的にviewを無効にする¶

現在のviewを削除せずに無効にしたい場合、 off という名前の仮想viewに切り替えることができます。これは、ツリー全体を一つか二つのコマンドで操作する必要があり(例: merge)、しかしその後に元のviewに戻りたい場合に便利です。

現在のviewを削除せずに無効にするには:

bzr view --switch off

ツリー全体に対する操作が終わったら、元のviewの名前を指定して戻ることができます。たとえば、デフォルトの名前が使われて他のであれば:

bzr view --switch my

viewを削除する¶

現在のviewを削除するには:

bzr view --delete

名前つきviewを削除するには:

bzr view --name view-name --delete

全てのviewを削除するには:

bzr view --delete --all

注意点¶

view を定義しても作業ツリー内のほかのファイルを削除するわけではありません。単に作業ツリーに対する “レンズ” を提供するだけです。

view は作業ツリーのメタデータとして保存されます。pull, push, update といったブランチコマンドを使っても他の作業ツリーに伝播しません。

view はファイルパスの形で定義されます。もしview内のファイルをview外に移動したのであれば、view はそのファイルを追跡しません。たとえば、viewが doc/ と定義されていて doc/NEWS を NEWS に移動しても view は doc/ に定義されたままで、 doc/ と NEWS のように変更されたりはしません。同じように、view内のファイルを削除してもviewからはそのファイルパスは削除されません。

現在のviewを利用するコマンドは:

status
diff
commit
add
remove
revert
mv
ls

ツリー全体に対する操作だけれども現在のviewの中だけを報告するコマンドは:

pull
update
merge.

現在のところ、多くのコマンドがviewを無視します。ニーズがあるコマンドから徐々に上の対応リストに追加されていくでしょう。いくつかのコマンドは全体図を見るのがより適しているために、viewを無視したままになるでしょう。このタイプのコマンドには次のものがあります:

log
info

スタックブランチを利用する¶

ユースケース¶

あるプロジェクトで作業しようとしていて、公開されているリポジトリに対して読み込みアクセスはできるものの書き込みができないとしましょう。公開されているリポジトリと同じホストで自分のブランチを公開したりバックアップしたりする場合、スタックブランチを使うことができるかもしれません。

スタックブランチの他のユースケースとしては、実験的なブランチと、コードホスティングサイトが挙げられます。これらのシナリオではスタックブランチの特性がぴったりあいます。

スタックブランチとは？¶

スタックブランチ(stacked branch)は別の(スタック先)ブランチのリビジョンを見つける方法を知っています。スタックブランチはスタック先ブランチには存在しないユニークなリビジョンのみを保存することで、ブランチの作成を高速にしたり、ディスク利用効率を向上します。これらの観点から、スタックブランチは共用リポジトリと似ています。しかしながら、スタックブランチは追加の利点があります:

新しいブランチはスタックされたブランチとは完全に異なる位置に設置できます。
スタックブランチを削除すれば(共用リポジトリだと残ってしまう) リビジョンの情報も削除されます
セキュリティは共用リポジトリよりも向上しています。スタック先のリポジトリはスタックブランチにコミットする開発者に対して物理的にリードオンリーだからです。

スタックブランチを作成する¶

スタックブランチを作成するには、branchコマンドの stacked オプションを使用します。例です:

bzr branch --stacked source-url my-dir

このコマンドによって my-dir がローカルリビジョンなしのスタックブランチとして作成されます。定義されると、 source-url に関連づけされた公開ブランチは スタックドオン(stacked on) の位置として使われます。さもなければ、 source-url は スタックドオン の位置になります。

スタックチェックアウトを作成する¶

スタックチェックアウトを直接作成する機能はまもなくサポートされる予定です。それまでの間、2段階の処理が必要です:

上記で示されたようにスタックブランチを作成する。
reconfigure もしくは bind コマンドのどちらかを利用してブランチをチェックアウトに変換する。

スタックブランチをプッシュする¶

多くのプロジェクトの大部分の変更は 開発トランク or 現在の安定 ブランチといった既存のブランチを基礎としています。これらの1つにスタックされた新しいブランチの作成は push コマンドを利用して次のように簡単にできます:

bzr push --stacked-on reference-url my-url

このコマンドでは、 reference-url にスタックした新しいブランチを my-url に作成し、 reference-url には無いリビジョンだけをそこに格納します。 my-url は reference-url と同じホストでも構いません。

ローカルブランチがスタックブランチとして作成された場合、 push するには --stacked オプションを使うことが可能でスタック先の位置を省略できます。:

bzr branch --stacked source-url my-dir
cd my-dir
(hack, hack, hack)
bzr commit -m "fix bug"
bzr push --stacked

この使い方は、上述したユースケースにマッチしています。

スタックブランチの制限¶

スタックブランチに関して覚えておくべき大事なことは、ほとんど全てのオペレーションでスタック先ブランチが必要になることです。これは両方のブランチがローカルもしくは同じサーバーにあるときは問題にはなりません。

また、ほとんどの履歴がスタック先リポジトリに格納されているので、スタック先リポジトリへのアクセスがネットワーク経由だった場合に bzr log のようなコマンドが遅くなるかもしれません。

スタックするブランチを変更する¶

bzr reconfigure コマンドを使ってスタックドオンブランチを変更したりスタックするのをやめたりすることができます。 bzr reconfigure --unstacked を実行した場合、bzrは全ての参照されているデータをスタックドオンブランチからスタックされていたブランチにコピーしてくることに注意してください。大きなレポジトリにおいては、これは時間がかかったりリポジトリサイズを増大させたりします。

スマートサーバーを稼働させる¶

BazaarはHTTP、FTPもしくはSFTPを通して動作するので特化したサーバーは必須ではありません。 SSH、inetd、もしくは専用モードで起動できるスマートサーバー(smart server)の選択肢があります。

ダムサーバー¶

HTTP、FTP、SFTPとHTTP-WebDAVを”ダム(dumb)”サーバーとして記述します。これらはBazaarに支援を提供しないからです。これらのプロトコルのどれかを通してBazaarリポジトリを利用できるようにする場合、 Bazaarはリモートからの読み込みを許可します。実行しているBazaarコマンドの中でブランチへのURLを入力するだけです。:

bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev

BazaarはFTP、SFTPと(プラグインを通した)HTTP-WebDAVを通した書き込みをサポートします。

ハイパフォーマンスなスマートサーバー¶

ハイパフォーマンスなスマートサーバー(hpss - high-performance smart server)はいくつかのオペレーションをダムサーバーよりも遙かに高速に実行します。開発者がパフォーマンスのチューニングを継続するので、将来のリリースではスマートサーバーを利用することで改善されるオペレーションの範囲は増えます。

高度なセキュリティの維持を可能にするために、デフォルトでは現在のスマートサーバーはリードオンリーになります。読み込みと書き込み権限を有効にするには、 --allow-writes で動かします。 SSHアクセスメソッドを利用するとき、bzrは --allow-writes オプションで自動的に実行します。

次はスマートサーバーの代替の設定方法を説明します。

SSH¶

SSHを通してBazaarを利用する際にサーバー上の特別な設定は必要ありません。サーバーに Bazaar がインストールされていれば、 bzr+ssh の URL を利用することができます。例:

bzr log bzr+ssh://host/path/to/branch

bzr がサーバーのシステムワイドな場所にインストールされていない場合、リモートの bzr がどこにあるかをローカルの bzr に教える必要があるかもしれません。

BZR_REMOTE_PATH=~/bin/bzr bzr log bzr+ssh://host/path/to/branch

BZR_REMOTE_PATH 環境変数はリモートシステムで bzr が起動する方法を調整します。デフォルトでは単に bzr として起動するので、 bzr 実行ファイルはデフォルトの検索パス上にあることが要求されます。この設定を場所ごとの設定ファイルである locations.conf に書いて永続化することもできます。

SFTP と同じく、 ~ で始まるパスはホームディレクトリからの相対パスになります。例えば bzr+ssh://example.com/~code/proj のようになります。加えて、 ~user は user のホームディレクトリからの相対パスになります。

inetd¶

この例では /srv/bzr/repo/branchname にブランチがある /srv/bzr/repo 内の共用リポジトリ用に専用ユーザーの bzruser で bzr を実行する方法を示しています。

inetdからBazaarサーバーを動かすにはinetd.confエントリが必要です:

4155  stream  TCP  nowait  bzruser  /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/repo

クライアントコマンドを実行するとき、提供するURLは inetd.confに渡される --directory オプションに相対的な bzr:// です:

bzr log bzr://host/branchname

可能であれば、 ~ や ~user で始まるパスは bzr+ssh と同じように展開されますが、 bzr serve に指定された --directory オプションの外にあるホームディレクトリにはアクセスできません。

専用サーバー¶

このモードはinetdモードと同じパスとURLのふるまいを持ちます。特定のユーザーとして実行するには、 su を使うもしくはそのユーザーとしてログインします。

この例では公式のポート番号の 4155 上でbzrを稼働しすべてのインターフェイス上でリスンします。これによってポート 4155 上のマシンに到達できる世界のどこからでも接続できます。

サーバー:

bzr serve --directory=/srv/bzr/repo

クライアント:

bzr log bzr://host/branchname

この例では localhost のポート 1234 で bzr serve が実行されます。

サーバー:

bzr serve --listen=localhost --port=1234 --directory=/srv/bzr/repo

クライアント:

bzr log bzr://localhost:1234/branchname

フックを利用する¶

フックとは？¶

Bazaarのふるまいをカスタマイズする1つの方法は フック(hook) です。フックによって特定のBazaarの特定のオペレーションの前後でアクションを実行できます。オペレーションは commit, push, pull と uncommit を含みます。フックとパラメータの完全なリストに関しては、ユーザーリファレンスのフックを参照してください。

大抵のフックはクライアントで実行されますが、サーバーで実行されるものもわずかにあります。 (サーバーサイドのオペレーションの特殊なケースを扱うものは push-and-update plugin も参照。)

フックを使用する¶

フックを使用するには、プラグインを書きます。新しいコマンドを作成する代わりに、このプラグインはフックを定義してインストールします。例です:

from bzrlib import branch

def post_push_hook(push_result):
    print "The new revno is %d" % push_result.new_revno

branch.Branch.hooks.install_named_hook('post_push', post_push_hook,
                                 'My post_push hook')

この例を使用するには、 push_hook.py という名前のファイルを作り plugins サブディレクトリに設置します。 (プラグインをインストールしていなければ、 plugins ディレクトリを作る必要があります)。

以上です！次回にpushすると、”The new revno is…”が表示されます。もちろん、Pythonのフルパワーを思いとおりにできるので、フックはこれよりもはるかに手が込んでいます。これでフックの使い方を理解したので、それらで何をするかはあなたしだいです。

プラグインのコードは2つのことを行います。最初に、これは push が完了した後に実行する関数を定義します。 (代わりにインスタンスメソッドもしくは呼び出し可能なオブジェクトを使用することもできます。) すべてのpushフックは単独の引数 push_result をとります。

2番目に、プラグインはフックをインストールします。最初の引数 'post_push' はフックがインストールされている場所を特定します。 2番目の引数はフック自身です。3番目の引数は 'My post_push hook' という名前で、これは進行メッセージとエラーメッセージで使用されます。

To reduce the start-up time of Bazaar it is also possible to “lazily” install hooks, using the bzrlib.hooks.install_lazy_named_hook function. This removes the need to load the module that contains the hook point just to install the hook. Here’s lazy version of the example above:

Bazaar のスタートアップ時間を短縮するために、フックを “遅延” インストールすることができます。遅延インストールには bzrlib.hooks.install_lazy_named_hook 関数を使います。遅延インストールを使えば、フックをインストールするためだけにフックポイントを含むモジュールをロードする必要がなくなります。次の例は、上の例の遅延バージョンです。

from bzrlib import hooks

def post_push_hook(push_result):
    print "The new revno is %d" % push_result.new_revno


hooks.install_lazy_named_hook('bzrlib.branch', 'Branch.hooks',
    'post_push', post_push_hook, 'My post_push hook')

フックをデバッグする¶

インストールされたフックの一覧 (と、利用可能なフックポイントの一覧) を表示するには、隠しコマンドである hooks コマンドを使います:

bzr hooks

例: マージプラグイン¶

次の例は Merger.merge_file_content フックのデモのための、完全なプラグインです。このプラグインは、 *.xml の名前のファイルに対する全てのマージに着いて、 Bazaar がそのマージがクリーンだと判断しても必ず「衝突」状態にします。

merge_xml.py:

"""Custom 'merge' logic for *.xml files.

Always conflicts if both branches have changed the file.
"""

from bzrlib.merge import PerFileMerger, Merger

def merge_xml_files_hook(merger):
    """Hook to merge *.xml files"""
    return AlwaysConflictXMLMerger(merger)

class AlwaysConflictXMLMerger(PerFileMerger):

    def file_matches(self, params):
        filename = self.get_filename(params, self.merger.this_tree)
        return filename.endswith('.xml')

    def merge_matching(self, params):
        return 'conflicted', params.this_lines

Merger.hooks.install_named_hook(
    'merge_file_content', merge_xml_files_hook, '*.xml file merge')

merge_file_content hooks are executed for each file to be merged. For a more a complex example look at the news_merge plugin that’s bundled with Bazaar in the bzrlib/plugins directory.

merge_file_content フックは各ファイルがマージされるたびに呼ばれます。もっと複雑な例として、 Bazaar の bzrlib/plugins ディレクトリに同梱されている news_merge プラグインも参照してください。

バージョンの情報をエクスポートする¶

詳細なバージョン情報を得る¶

最新バージョンに関する詳細な情報を出力するには version-info コマンドを使用できます:

$ bzr version-info
revision-id: pqm@pqm.ubuntu.com-20071211175118-s94sizduj201hrs5
date: 2007-12-11 17:51:18 +0000
build-date: 2007-12-13 13:14:51 +1000
revno: 3104
branch-nick: bzr.dev

オペレーティングシステムツールもしくはスクリプトを使用して出力を簡単にフィルタリングできます。例です:

$ bzr version-info | grep ^date
date: 2007-12-11 17:51:18 +0000

より高度な後処理のためにすべてのリビジョンに関するバージョン情報が必要であれば、 --all オプションはその情報を実際にダンプします。

Pythonのプロジェクト¶

プロジェクトファイルをビルドするためにMakefileを使う場合、次のようにバージョン情報用のファイルを簡単に生成できます:

library/_version.py:
      bzr version-info --format python > library/_version.py

これは3つのディレクトリを含むファイルを生成します:

version_info: 現在の状態に関する基本情報を含むディレクトリ。

revisions: コミット時間とコミットメッセージと一緒に、ツリーの履歴の中のすべてのリビジョンのリストを表示するディクショナリ。 --all もしくは --include-history が提供されない限り、デフォルトではこれは空です。リリースバージョンに含まれる、バグ修正などを追跡したい場合に便利です。しかし多くのプロジェクトに対してこれは必要以上の情報です。

file_revisions: プロジェクトのすべてのファイルに対する最終修正のリビジョンのリストを示すディクショナリ。これは $Id$ キーワードがCVSで管理されたファイルと同じように使われます。最終修正の日付は revisions マップで探すことで決定されます。デフォルトではこれは空で、 --all もしくは --include-file-revisions によってのみ有効になります

別のフォーマットでバージョン情報を得る¶

任意のフォーマットのバージョン情報を取得するためにBazaarはテンプレートベースの方法をサポートします。 version-info への --custom オプションは作業ツリーのステータスに基づいて拡張された変数を含む --template 引数を提供することで使用できます。

たとえば、現在のリビジョン番号を含むフォーマットされた文字列を伴うCヘッダーファイルを生成するには:

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

{revno} は作業ツリーのリビジョン番号に置き換えされます。 (上記の例があなたのOSで動作しない場合、一行ですべてのコマンドを入力してみてください) テンプレートの中で利用できる変数の詳細な情報に関しては、 Bazaarのユーザーリファレンスの Version Info を参照してください。

特定の言語でバージョン情報をダンプするために予め定義されるフォーマットはは現在開発段階にあります。この領域の要求に関してはメーリングリストで私達開発者に連絡して下さるようお願いします。

チェッククリーン¶

プロジェクトの内容に関する大抵の情報はリビジョンエントリを読むだけで簡単に決定できます。しかしながら、作業ツリーがパッケージされたときにそれが最新であったこと、もしくはローカルな修正があったことを知るためには便利です。 --all もしくは --check-clean のどちらかを提供することで bzr は作業ツリーを検査して、 version_info clean を設定します。同様に modified が適切である場合に file_revisions でエントリを設定します。

Bazaarを環境に統合する¶

ウェブブラウジング¶

概要¶

BazaarのリポジトリをWeb上で閲覧するために利用できる選択肢は幅広くあり、主要なものは Loggerhead です。 Loggerhead のホームページは https://launchpad.net/loggerhead にあります。

ダウンロードリンクを含めてこれらのパッケージの最新情報に関しては http://wiki.bazaar.canonical.com/WebInterface を参照してください。

注: プロジェクトがホストされているもしくはLaunchpadでミラーリングされている場合、 Loggerheadのコードブラウジング機能はサービスの一部として提供されます。

バグトラッカー¶

Bazaarにはコミットをプロジェクトのバグトラッカーのバグに関連づけできる機能があります。コミットとバグの間のハイパーリンクを生成する、もしくはコミットを含むブランチで閉じたバグを自動的にマークするために、他のツール (もしくはフック) はこの情報を使うことができます。

コミットとバグを関連付ける¶

コミットを行うとき、 commit の --fixes オプションを利用することでバグと関連付けることができます。例です:

$ bzr commit --fixes lp:12345 -m "Properly close the connection"

このコマンドの実行によってコミットとLaunchpdのバグ12345とリンクするBazaarのメタデータが記録されます。異なるバグトラッカーを使う場合、( lp の代わりに) 独自のトラッカーコードを渡して代わりに使うことができます。 Bugzilla、Trac、Roundupとその他のバグ/問題トラッカーに対してこれを設定する方法の詳細に関しては、 Bazaarユーザーリファレンスのバグトラッカーの設定を参照してください。

メタデータの記録 vs バグトラッカーの更新¶

コミット時に修正されたバグに関するメタデータの記録は完全なバグトラッカーの統合機能の中で唯一必要なものです。 Bazaarは分散型VCSなので、ユーザーがオフラインでコミットしているためバグトラッカー自身へのアクセスが不可能な場合があります。代わりに、プロジェクトのワークフローに適切な中心位置に変更をpushするとき、バグトラッカーを更新するためにフックをインストールすることが推奨されます。

注: この2番目の処理段階はLaunchpadの外部もしくはホストされているブランチがスキャンされるときに Launchpadによって提供される統合機能の一部です。

訂正をする¶

リビジョンとバグを関連付けるこの方法にはいくつかの制限があります。最初のものは関連づけはコミット時のみにしかできないことです。このことは、コミットするもしくは修正した後でバグが報告することを忘れた場合、一般的に後から差し戻してリンクを追加できないことを意味します。

これに関連したことは関連づけは不変であるという事実です。バグがあるコミットによって修正されたものとしてマークされたが、リビジョンがバグを十分に解決しない、もしくは後で回帰がある場合、差し戻してリンクを削除できません。

もちろん、正しいオプションで行うために最新コミットをアンドゥする bzr uncommit が常に使われます。これは正しくないコミットメッセージを訂正するためによく行われ、(たとえば --fixes を通した)最新コミットに記録されたメタデータを訂正するために等しく当てはまります。

注: 正しくないリビジョンが公開される前に uncommit を行うのがベストです。

付録¶

リビジョンを指定する¶

リビジョンの識別子と範囲¶

Bazaarは1つのリビジョンもしくはリビジョンの範囲を指定するための豊富な表現方法を持ちます。リビジョンの範囲を指定するには、上限と下限を .. のシンボルで区切ります。例です:

$ bzr log -r 1..4

境界値の片方を省略できます:

$ bzr log -r 1..
$ bzr log -r ..4

コマンドの中には範囲ではなく1つのリビジョンだけをとるものがあります。例です:

$ bzr cat -r 42 foo.c

他の場合、範囲は必要ですが、範囲の長さを1つにします。これに関連したコマンドについて、 -c オプションは次のように使われます:

$ bzr diff -c 42

利用可能なリビジョンの識別子¶

リビジョン、もしくは範囲の境界、は下記に示される異なるフォーマットを利用して渡すことができます。

引数の型説明

number リビジョン番号

revno:number リビジョン番号

last:number 負のリビジョン番号

guid グローバルでユニークなリビジョンID

revid:guid グローバルでユニークなリビジョンID

before:rev ‘’rev’‘の左端の親

date-value 渡された日付の後の最初のエントリ

date:date-value 渡された日付の後の最初のエントリ

tag-name 渡されたタグにマッチするリビジョン

tag:tag-name 渡されたタグにマッチするリビジョン

ancestor:path ブランチからのマージされた最新のリビジョン

branch:path 別のブランチの最新リビジョン

submit:path 投稿ブランチの共通の祖先

これらのフォーマットの手短な紹介は下記のとおりです。完全な詳細内容に関しては、 Bazaarユーザーリファレンスのリビジョンの識別子を参照してください。

番号¶

正の数は現在のブランチにおけるリビジョン番号を表します。リビジョン番号は bzr log の出力の中で “revno”とラベルされます。最初の10のリビジョンのログを表示するには:

$ bzr log -r ..10

負の数は最新リビジョンから数えます。-1は最後にコミットされたリビジョンです。

最新の10のリビジョンのログを表示するには:

$ bzr log -r -10..

revid¶

revid は bzr log --show-ids や他のコマンドによって示される内部のリビジョンIDの指定を可能にします。

例です:

$ bzr log -r revid:Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df

before¶

before: ‘’rev’‘は’‘rev’’ の左端の親を指定します。これはリビジョンの履歴で ‘’rev’’ の前に現れるリビジョン、もしくは ‘’rev’’ がコミットされたときに最新であったリビジョンです。

‘’rev’’ はリビジョンの識別子であり連結できます。

例です:

$ bzr log -r before:before:4
...
revno: 2
...

date¶

date: ‘’value’’ は真夜中もしくは指定された時刻での与えられた日付の、深夜12時か指定された時刻の後の最初の履歴エントリにマッチします。

正式な値は次のとおりです:

yesterday

today

tomorrow

YYYY-MM-DD 書式の日付

YYYY-MM-DD,HH:MM:SS 書式の日付/時間、2番目はオプションです (コンマに注意)

“今日のログエントリすべてをください”ということを伝える適切な方法は次のとおりです:

$ bzr log -r date:yesterday..date:today

Ancestor¶

ancestor:path: 現在のブランチと異なるブランチ間の共通の祖先を指定します。これはマージの目的に使われる同じ祖先です。

path はリモートブランチのURLもしくはローカルブランチへのファイルパスになります。

たとえば、 ../parent からフォークされた以降のブランチで行われた変更を見るには:

$ bzr diff -r ancestor:../parent

Branch¶

branch: path は別のブランチの最新リビジョンを指定します。

path はリモートブランチのURLもしくはローカルブランチへのファイルパスです。

たとえば、手元のブランチと別のブランチの間の違いを取得するには:

$ bzr diff -r branch:http://example.com/bzr/foo.dev

作業スペースを構成する¶

一般的なレイアウト¶

Bazaarのユーザーがプロジェクトのための作業スペースを構成するベストな方法は、次のような要素に依存します:

ユーザーの役割: プロジェクトオーナー vs コア開発者 vs カジュアルな貢献者
ワークフロー: プロジェクトが推奨/強制している、貢献のためのワークフロー
サイズ: 大きいプロジェクトは小さいプロジェクトよりもリソースを要求します。

少なくとも4つの一般的なワークスペースの構成方法があります。

lightweight checkout
standalone tree
feature branches
switchable sandbox.

各レイアウトの簡単な説明を以下に記します。

軽量チェックアウト¶

このレイアウトでは、作業ツリーはローカルですがブランチはリモートにあります。これはCVSやSVNで一般的に利用されるレイアウトで、シンプルで簡単に理解できます。

セットアップするには:

bzr checkout --lightweight URL project
cd project

作業するには:

(make changes)
bzr commit
(make changes)
bzr commit

各コミットが暗黙的に変更を同じブランチを利用している他の人に公開していることに注意してください。ただし、コミットが成功するには作業ツリーがリモートのブランチの最新の状態になっている必要があります。最新のコードを取得してマージするには、:

bzr update

スタンドアロンツリー¶

このレイアウトでは、作業ツリーとブランチは一つの場所にあります。共有リポジトリが上位のディレクトリに無い限り、リポジトリも同じ場所に格納されます。これはBazaarのデフォルトレイアウトで、小規模から中規模の大きさのプロジェクトに適しています。

セットアップ:

bzr branch URL project
cd project

作業:

(make changes)
bzr commit
(make changes)
bzr commit

変更を中央の場所に公開する:

bzr push [URL]

pushするURLは最初の一回だけ要求されます。

もし中央の場所が、pushするまでの間に他のユーザーからの変更を受け取っていた場合、pushする前にそれらの変更をローカルブランチにmergeする必要があります:

bzr merge
(resolve conflicts)
bzr commit

代替手段として、チェックアウトを使うこともできます。ブランチと同じようにチェックアウトも履歴全体をローカルにコピーしますが、ローカルブランチがリモートの場所に束縛されているので、両方のブランチに一度にコミットされます。

注意: チェックアウトはローカルコミット+pushに比べてスマートです。チェックアウトはまずリモートにコミットして、それが成功したときにだけローカルにもコミットします。

機能ブランチ¶

このレイアウトでは、いくつかのブランチとツリーがあって、一般的にリポジトリを共有します。一つのブランチは “trunk” のミラーを保存していて、それ以外の作業単位(例:バグ修正や機能追加)にはそれぞれの “機能ブランチ” を作ります。このレイアウトはほとんどのプロジェクト、特に中規模のものにとって理想的です。

セットアップ:

bzr init-repo project
cd project
bzr branch URL trunk

機能ブランチを開始する:

bzr branch trunk featureX
cd featureX

作業する:

(make changes)
bzr commit
(make changes)
bzr commit

変更をメーリングリストに公開してレビュー&承認してもらう:

bzr send

変更を公開ブランチで公開する(たとえばLaunchpad上でmerge要求を出すために):

bzr push [URL]

変化形として、trunkをチェックアウトとして作ることもできます。もしtrunkへのコミット権限を持っているのであれば、trunkへマージしてコミットするとその変更は暗黙的に公開されます。他には、trunkのURLが読み込み専用だった場合(例: HTTP アドレス)、チェックアウトを利用することはローカルのtrunkミラーに間違えて変更を登録してしまうことを防止します。これはプロジェクトがPQMなどのゲートキーパー型のワークフローを利用していたときに有用です。

ローカルのsandbox¶

このレイアウトは機能ブランチのレイアウトとほぼ同じですが、機能ブランチがそれぞれ作業ツリーを持つ代わりに一つの作業ツリーを共用する点が違います。これはgitのデフォルトレイアウトに似ていて、大きなツリー(10000ファイル以上とか)を持つプロジェクトや、ビルドによる加工物(.oや.classファイルといった)を大量に作るプロジェクトに適しています。

セットアップ:

bzr init-repo --no-trees project
cd project
bzr branch URL trunk
bzr checkout --lightweight trunk sandbox
cd sandbox

これでsandboxで作業を開始できますが、sandboxがtrunkを参照したままコミットしてしまうと、(trunkがcheckoutで無い限り)trunkが元のtrunkのミラーではなくなってしまいます。なので、まず機能branchを作ってsandboxをそちらに紐づけましょう:

bzr branch ../trunk ../featureX
bzr switch ../featureX

この後の、変更を行ったりその変更を公開して適用してもらうまでのプロセスは機能ブランチレイアウトの時と同じです。

進んだレイアウト¶

お望みとあれば、あなたのお好みの構成に合わせてレイアウトを決めることができます。例やアイデアについては共有リポジトリのレイアウトを参照してください。

共用レポジトリのレイアウト¶

Bazaarは共用ブランチ内部のブランチのレイアウトを柔軟に決められるように設計されました。この柔軟性によってユーザーはBazaarを自分のワークフローに合わせることができますが、”よい”レイアウトとは何かということを疑問に持つようになります。ここでは代わりになるものをいくつか説明しそれぞれの利点を検討します。

言及すべき重要な点はよいレイアウトは”一般的な”ユーザーが理解できるようにブランチの内容を何らかの形でハイライトします。 SVNにおいてこれは “trunk/” ブランチであると考えられ、大抵のレイアウトではこの命名規約が守られています。これを “mainline” もしくは “dev” と呼ぶ人もいれば、 CVSから来た人々はしばし “HEAD” と言及します。

“SVN形式” (`trunk/`, `branches/`)¶

SVNからやってきた人々は次のような”標準的な”プロジェクトのレイアウトに慣れています:

repository/       # リポジトリ全体
 +- trunk/        # 開発のメインライン
 +- branches/     # コンテナディレクトリ
 |   +- foo/      # 開発中のfoo機能用ブランチ
 |     ...
 +- tags/         # コンテナディレクトリ
     +- release-X # 特定のリリースバージョンをマークするために専用ブランチ
        ...

Bazaarでは、これは完全に適切なレイアウトです。 SVNからやって来た人が慣れ親しめることが利点で開発の焦点を当てる場所が明確になります。

同じリポジトリで複数のプロジェクトを持つとき、SVNのレイアウトは何を行うのか少し不透明です。

project/trunk¶

SVN用の望ましい方法はプロジェクトごとにレイアウト用のトップレベルのディレクトリを用意することです:

repository/            # リポジトリ全体
 +- project1/          # コンテナディレクトリ
 |   +- trunk/         # project1の開発のメインライン
 |   +- branches/      # コンテナディレクトリ
 |       +- foo/       # project1のfoo機能の開発用ブランチ
 |         ...
 |
 +- project2/          # project2用のコンテナ
     +- trunk/         # project2用のメインライン
     +- branches/      # project2のブランチ用のコンテナ

これはBazaarでも機能します。しかしながら、Bazaarでリポジトリを作るのは簡単で( bzr init-repo )、それらの主要な恩恵を受けられるのは複数のブランチが共通の祖先を共有するときです。

ですのでBazaarに対して望ましい方法は次のとおりです:

project1/          # project1用のリポジトリ
 +- trunk/         # project1の開発のメインライン
 +- branches/      # コンテナディレクトリ
     +- foo/       # project1のfoo機能の開発用ブランチ
       ...

project2/          # project2用のリポジトリ
 +- trunk/         # project2用のメインライン
 +- branches/      # project2のブランチ用のコンテナ

trunk/project¶

SVNで次のようなレイアウトを利用するプロジェクトもたまにあります:

repository/             # リポジトリ全体
  +- trunk/             # コンテナディレクトリ
  |   +- project1       # project1用のメインライン
  |   +- project2       # project2用のメインライン
  |         ...
  |
  +- branches/          # コンテナ
      +- project1/      # コンテナ (?)
      |   +- foo        # project1の'foo'ブランチ
      +- project2/
          +- bar        # project2の'bar'ブランチ

次のレイアウトはちょっと変形させたものです:

repository/             # リポジトリ全体
  +- trunk/             # コンテナディレクトリ
  |   +- project1       # project1用のメインライン
  |   +- project2       # project2用のメインライン
  |         ...
  |
  +- branches/          # コンテナ
      +- project1-foo/  # project1の'foo'ブランチ
      +- project2-bar/  # project2の'bar'ブランチ

“trunk/” 全体をチェックアウトすることで、すべてのプロジェクト用のメインラインを入手できるようにすることが、このレイアウトが採用されている理由だと筆者は考えます。

このレイアウトはBazaarでも使えますが、一般的にお勧めできません。

一回の bzr branch/checkout/get は一つのブランチを作ります。単独のコマンドですべてのメインラインを入手する利点が得られません。 [1]

repository/trunk/foo が foo プロジェクトの trunk か trunk ブランチの単なる foo ディレクトリなのか明らかではありません。この混乱の一部はSVNによるものです。 SVNはプロジェクトのブランチ用に使う1つのプロジェクトのファイルに対して同じ”名前空間”を使うからです。 Bazaarにおいて、プロジェクトを構成するファイルの明確な定義、もしくはブランチの位置の対立軸があります (ブランチごとに唯一の .bzr/ ディレクトリか、チェックアウトの中にたくさんの .svn/ ディレクトリかという対立軸です)

[1]	注: NestedTreeSupport は”メタプロジェクト”を作成する方法を提供します。メタプロジェクトはリポジトリのレイアウトにかかわらず複数のプロジェクトを集約します。 1つのプロジェクトを `bzr checkout` すれば、必要なサブプロジェクトがすべて手に入ります。

入れ子形式 (`project/branch/sub-branch/`)¶

SVNではできない、Bazaarによる別のスタイルは、ブランチ同士を入れ子にすることです。 Bazaarは作業ツリーなしのリポジトリ作成(--no-trees)をサポート(と推奨)しているのでこのスタイルが可能になります。作業ファイルはブランチの設置場所に混ぜられていないので、好きな名前空間にブランチを設置できます。

1つの可能性は次のとおりです:

project/             # リポジトリ全体、*と* プロジェクトのメインラインのブランチ
 + joe/              # 開発者Joeの開発のプライマリブランチ
 |  +- feature1/     # 開発者Joeのfeature1開発ブランチ
 |  |   +- broken/   # feature1を開発するためのステージングブランチ
 |  +- feature2/     # Joeのfeature2開発ブランチ
 |    ...
 + barry/            # Barryの開発ブランチ
 |  ...
 + releases/
    +- 1.0/
        +- 1.1.1/

このレイアウトのアイディアはブランチ用の階層的なレイアウトを作ることです。変更はたいていより上位の名前空間のブランチへと流れていきます。また、このレイアウトではユーザーに独自の作業をするための場所も提供します。このレイアウトの素晴らしい点の1つは、グローバルな branches 名前空間を散らかさずにミニブランチを置けるので、ブランチ作成が”手軽”になることです。

このレイアウトのもう一つの利点は、ブランチの名前の中で詳細な内容を指定する際に繰り返しが減ることです。

例です:

bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/

上と下を比較します:

bzr branch http://host/project/joe/foo/bugfix-10

また、 repository/project/branches/ ディレクトリの中のリストがあれが何かわかるかもしれません:

barry-feature-bar/
barry-bugfix-10/
barry-bugfix-12/
joe-bugfix-10/
joe-bugfix-13/
joe-frizban/

Versus こういったブランチが開発者のディレクトリに分散している。ブランチの数が少なければ、 branches/ は一見するだけですべてのブランチが見えるという素晴らしい利点があります。ブランチの数が多ければ、 branches/ はすべてのブランチが見えてしまうというはっきりした欠点があります。 (調べるブランチが100あるとき、興味のあるブランチを見つけるのが難しくなります)。

入れ子ブランチはたくさんのブランチよりもスケーラブルのようです。しかしながら、それぞれの個別のブランチは見つけにくいです。 (たとえば”Joeはfoo機能ブランチでバグ修正10に取り組んでいるのか、それともbarの機能ブランチを取り組んでいるのか？”)

他の小さな利点は次のようなものです:

 bzr branch http://host/project/release/1/1/1
もしくは
 bzr branch http://host/project/release/1/1/2

1.1.1と1.1.2のリリースを示します。これはリリースする数と一度に見られる能力よりも分割する方がゲインが多いかによります。

ステータスによる種類分け (`dev/`, `merged/`, `experimental/`)¶

ブランチをbreak upする他の方法はこれらを現在のステータス順でソートすることです。そうするとレイアウトは次のようになります:

project/               # レイアウト全体
 +- trunk/             # 開発に焦点を当てたブランチ
 +- dev/               # 進行中の作業用コンテナディレクトリ
 |   +- joe-feature1   # Joeの現在のfeature-1ブランチ
 |   +- barry-bugfix10 # bugfix 10に対するBarryの作業内容
 |    ...
 +- merged/            # これらのブランチがマージされたことを示すコンテナ
 |   +- bugfix-12      # すでにマージされたバグ修正
 +- abandonded/        # 'dead-end'と見なされているブランチ

これはたくさんの利点と欠点があります。あまり多くない数のアクティブに開発されているブランチを見ることができるか、今までに作られた全てのブランチが見えるかという違いがあります。古いブランチは削除しない限り失われませんが、別ディレクトリへと整理されるのでたいていの場合お目当てのブランチを見つけやすくなります。 (反対に、古いブランチは見つけにくくなります)。

このレイアウトで最大の欠点、ブランチが移動することです。誰かが project/dev/new-feature ブランチをフォローしているとき、そのブランチが trunk/ にマージされると project/merged/new-feature に移動するので bzr pull が突然機能しなくなります。この回避策はいくつかあります。 1つは利用者を導くために古いブランチから新しいブランチにリクエストするHTTPリダイレクトを使うことです。 bzr >= 0.15 ではユーザーに http://old/path が http://new/path にリダイレクトされることを教えてくれます。しかしながら、HTTP以外の方法(SFTP、ローカルファイルシステム、など)を通してブランチにアクセスしている場合は役に立ちません。

一時的なリダイレクト用にシンボリックリンクを利用することも可能です (シンボリックリンクがリポジトリ内にある限りトラブルはほんのわずかしかありません)。しかし、シンボリックリンクを結局削除したくなったり、散乱の削減の恩恵を得られません。シンボリックリンクの代わりの別の可能性は BranchReference を使うことです。 bzr コマンドを通してこれらを作るのは現時点では難しいですが、便利だと思う人がいれば変わるかもしれません。これは実際には Launchpad が bzr checkout https://launchpad.net/bzr をできるようにしている方法です。 BranchReference は機能的にはシンボリックリンクですが、他のURLの参照ができます。相対パスによる参照ができるように拡張されれば、HTTP、SFTP、ローカルパスを通しても動作するでしょう。

日付/リリース/その他で種類分け (`2006-06/`, `2006-07/`, `0.8/`, `0.9`)¶

スケーラビリティを可能にする別の方法は”現在の”ブランチのブラウジングを許可することです。基本的に、活発に開発されるブランチは新しく作られ古いブランチはマージもしくは廃棄されることを前提とします。

基本的に日付レイアウトは次のようになります:

project/                # projectリポジトリ全体
 +- trunk/              # 一般的なメインライン
 +- 2006-06/            # この月に作成されたブランチ用のディレクトリのコンテナ
 |   +- feature1/       # "project"の"feature1"用ブランチ
 |   +- feature2/       # "project"の"feature2"用ブランチ
 +- 2005-05/            # 異なる月に作成されるブランチ用のコンテナディレクトリ
     +- feature3/
     ...

これは “私の新しいブランチをどこに設置すればいいの？” という質問に素早く答えてくれます。機能が長期間開発されるのであれば、ブランチを最新の日付にコピーして、そこで作業を続けることも道理にかなっています。最新の日付と、そこからのさかのぼっていくことで活発なブランチを見つけることができます。 (小さな欠点は大抵のディレクトリリストは古い順にソートされているので、多くの場合新しいブランチにたどり着くために余計なスクロールが必要になることです)。古いブランチを新しい位置にコピーしたくない場合、ブランチを探すのが面倒になるのも欠点です。

別の候補は、リリースをターゲットにしたものです:

project/          # リポジトリ概要
 +- trunk/        # メインラインの開発ブランチ
 +- releases/     # リリースブランチ用のコンテナ
 |   +- 0.8/      # リリース0.8のブランチ
 |   +- 0.9/      # リリース0.9のブランチ
 +- 0.8/          # リリース0.8をターゲットとするブランチ用のコンテナ
 |   +- feature1/ # 0.8にマージする予定の"feature1"用のブランチ
 |   +- feature2/ # "リリース0.8をターゲットとしたfeature2"用のブランチ
 +- 0.9/
     +- feature3/ # リリース0.9をターゲットとした"feature3"用のブランチ

その派生として、ブランチが 0.9 ディレクトリに入っていることが 0.9に 向けた ブランチであることではなく 0.9 から派生したブランチであることを意味するようにすることや、 0.8/release が0.8ブランチの公式リリースであることを意味するようにすることが考えられます。

一般的なアイディアはリリースをターゲットにすることで、何のブランチがマージされるのを待っているのか調べることができます。このレイアウトはブランチの状態(開発中なのか、終了してレビューを待っているのか)に関する情報を提供しません。これは履歴を隠す効果もあり、日付ベースの種類分けと同じような利点と欠点を持っています。

シンプルな開発者名 (`project/joe/foo`, `project/barry/bar`)¶

別の利用できるレイアウトは、開発者ごとにディレクトリを割り当てて、その下にブランチのためのサブディレクトリを作ることです。次のようになります:

project/      # リポジトリ全体
 +- trunk/    # メインラインのブランチ
 +- joe/      # Joeのブランチ用のコンテナ
 |   +- foo/  # Joeの"project"の"foo"ブランチ
 +- barry/
     +- bar/  # Barryの"project"の"bar"ブランチ

このアイデアでは、branchは入れ子になっておらず、branchは開発者によってのみグループ化されます。

Launchpad で使われている派生系はこのようになっています:

repository/
 +- joe/             # Joeのブランチ
 |   +- project1/    # Joeのブランチである"project1"用のコンテナ
 |   |   +- foo/     # Joeの"project1"の"foo"ブランチ
 |   +- project2/    # Joeの"project2"ブランチ用のコンテナ
 |       +- bar/     # Joeの"project2"の"bar"ブランチ
 |        ...
 |
 +- barry/
 |   +- project1/    # Barryの"project1"のブランチ用のコンテナ
 |       +- bug-10/  # Barryの"project1"の"bug-10"ブランチ
 |   ...
 +- group/
     +- project1/
         +- trunk/   # "project1"に焦点をあてたメイン開発

このレイアウトではそれぞれの開発者が取り組んでいるものを簡単に見ることができます。焦点のブランチは”group” ディレクトリに保存されます。これによって”グループ”が取り組んでいるブランチを見分けられます。

これによって異なる人々の作業内容をそれぞれ分離できますが、”プロジェクトX用のすべてのブランチ”を見つけるのが難しくなります。 Launchpad はデータベースバックエンドを伴う素晴らしいウェブインターフェイスを提供していて、”view”をこのレイアウトのトップに追加することでこの欠点を補っています。これはそれぞれの個人が “~/public_html” ディレクトリを持ち、そこで独自のウェブページを公開する個人用ホームページのモデルに近いです。一般的に、集中型のプロジェクト用に共用リポジトリを作成するとき、個人単位で分割してからプロジェクト単位に分割することを望まないでしょう。通常はプロジェクト単位で分割してから個人単位で分割するとよいでしょう。

要約¶

最後に、誰にとってもうまくいく唯一の命名規則はありません。開発者の人数、新しいブランチが作成される頻度、ブランチのライフサイクルなどによって異なります。自身に問いかける質問は次のとおりです:

寿命の長い少数のブランチを作るか、もしくはたくさんの”ミニ”機能ブランチを作るか (加えて: ミニ機能ブランチをたくさん 作りたい が現在のVCSでは苦痛なのでできないのではないか？)

1人で開発しているのか、大きなチームか？

チームであれば、一般的に全員が同時に同じブランチに取り組むことを計画しているか？もしくは人々が追跡することを想定した”安定”ブランチを持つか。

Eメールを設定する¶

なぜBazaarでEメールアドレスをセットアップするのか？¶

リビジョンが作成されたとき誰がどのリビジョンをコミットしたのかわかるように Bazaarは指定されたEメールアドレスをリビジョンに保存します。 Eメールアドレスは検証されないので、それゆえ偽造できるので、プロジェクトに関わる人々を信用しなければなりません。

加えて、リビジョンのEメールアドレスはクレジットかつ/もしくは注釈に関してリビジョンの筆者とコンタクトをとる別の方法を提供します。

Eメールアドレスをセットアップする方法¶

Eメールアドレスが設定されていない場合、Bazaarはユーザー名とホスト名に基づいて推測を試みます。これは望む状況ではないかもしれないので、Bazaarに使うメールを伝える方法は3つ存在します:

いくつかの設定ファイルの1つにEメールを設定できます。他の設定値のように、 bazaar.conf で一般的な設定として設定できます。特定のブランチ、もしくは複数のブランチの一式用に値を上書きしたい場合、 locations.conf を利用できます。 .bzr/branch/branch.conf も動作しますが、他の人であってもそのブランチへのすべてのコミットで同じEメールアドレスが使われます。

優先順位は

BZR_EMAIL 環境変数が設定されている場合

Eメールが現在のブランチの locations.conf ファイルに対して設定されている場合。

Eメールが現在のブランチの .bzr/branch/branch.conf ファイルに設定されている場合。

Eメールがデフォルトの bazaar.conf 設定ファイルで設定されている場合。

EMAIL 環境変数が設定されている場合

Bazaarはユーザー名とホスト名から推測しようとします。

Bazaarが現在のEメールと考えるものを確認するには、 whoami (“who am i?”) コマンドを使います:

% bzr whoami
Joe Cool <joe@example.com>

‘whoami’コマンドでEメールを設定する¶

Eメールをグローバルに設定するにはwhoamiコマンドを使用します:

% bzr whoami "Joe Cool <joe@example.com>"

もしくは現在のブランチのみの場合:

% bzr whoami --branch "Joe Cool <joe@example.com>"

これらのコマンドによってグローバルな bazaar.conf もしくはブランチの branch.conf ファイルがそれぞれ修正されます。

デフォルトの設定ファイルでEメールを設定する¶

デフォルトのiniファイルを使うには、 bazaar.conf ファイル (Unix では ~/.bazaar/ 、Windowsでは %APPDATA%\bazaar\2.0\ )を作成し編集して下記で示すようにEメールアドレスを設定します。 DEFAULTは大文字と個別を区別して、大文字でなければならないことに注意をお願いします。

[DEFAULT]
email=Your Name <name@isp.com>

iniファイルのフォーマットの詳細情報に関しては、Bazaarユーザーリファレンスの構成設定を参照してください。

ブランチ単位でEメールを設定する¶

2番目のアプローチは locations.conf 設定ファイルを使用してブランチごとにEメールを設定する方法です:

[/some/branch/location]
email=Your Name <name@other-isp.com>

これによってブランチのEメールアドレスは /some/branch/location に設定され、上記の bazaar.conf で指定されたデフォルトの値を上書きします。

環境変数を通してEメールを設定する¶

Bazaarが利用する最後の方法は BZR_EMAIL と EMAIL 環境変数に対するチェックです。一般的に、スクリプトのコンテキストでEメールを上書きするためにこの方法を利用できます。一般的なデフォルトの値に設定したい場合、上記のiniの方法を参照して下さるようお願いします。

スパムに関する懸念事項¶

スパムの標的にされないようにEメールアドレスを共有したくない人達がいます。公開された場所で自分でブランチもしくはチェンジセットを公開しない限り、BazaarはけっしてEメールアドレスを露出しません。他の人があなたに作業内容に関して連絡できるように実際のアドレスを使うことを強くお勧めしますが、必須ではありません。メールアドレスは難読にしたり、宛先がわからず戻ってくるようにする、もしくは spamgourmet.cm のようなアンチスパムサービスの検査をうけさせたりします。

Apache を使って Bazaar サーバーをたてる¶

このドキュメントでは、 Apache 2.0 と FastCGI, mod_python, mod_wsgi のどれかを利用して Bazaar の HTTP スマートサーバーをセットアップする方法を説明します。

スマートサーバーに関する詳細な情報とそれを設定する他の方法に関しては、スマートサーバーのドキュメントを参照してください。

例¶

プレーンなHTTPで /srv/example.com/www/code を http://example.com/code/… としてすでに公開しているとします。これはbzrのブランチと /srv/example.com/www/code/branch-one と /srv/example.com/www/code/my-repo/branch-two のようなディレクトリを含みます。既存のHTTP形式のアクセス権限に加えてリードオンリーのスマートサーバーのアクセス権限をこれらのディレクトリに提供したい場合を考えます。

Apache 2.0を設定する¶

FastCGI¶

最初に、mod_fastcgiを設定します。たとえば次の行をhttpd.confに追加します:

LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so
FastCgiIpcDir /var/lib/apache2/fastcgi

我々の例では、http://example.com/code で /srv/example.com/www/code をすでに提供しているので既存のApacheの設定は次のようになります:

Alias /code /srv/example.com/www/code
<Directory /srv/example.com/www/code>
    Options Indexes
    # ...
</Directory>

.bzr/smartの形式で終わるURLに対するすべてのリクエストを扱うために次のように変更する必要があります:

Alias /code /srv/example.com/www/code
<Directory /srv/example.com/www/code>
    Options Indexes FollowSymLinks
    RewriteEngine On
    RewriteBase /code
    RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
</Directory>

# bzr-smart.fcgiはDocumentRootの元に存在しないので、実行されるように
# AliasはこれをURLの名前空間のエイリアスにする。
Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
<Directory /srv/example.com/scripts>
    Options ExecCGI
    <Files bzr-smart.fcgi>
        SetHandler fastcgi-script
    </Files>
</Directory>

この設定はFastCGIを通して /code 内部の /.bzr/smart で終わるURLに対する Bazaarのスマートサーバーへのリクエストを扱うようにApacheに指示します。

詳細な情報は mod_rewrite と mod_fastcgi のドキュメントを参照してください。

mod_python¶

最初に、次のようなコードを httpd.conf に追加して mod_python を設定します:

LoadModule python_module /usr/lib/apache2/modules/mod_python.so

FastCGI と同じ方法で mod_rewrite を用いて書き換えルールを定義します:

RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi

変更は次のようになります:

RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.py

mod_fastcgi のように、スクリプトがどのように扱われるのかも定義します:

Alias /srv/example.com/scripts/bzr-smart.py /srv/example.com/scripts/bzr-smart.py
<Directory /srv/example.com/scripts>
    <Files bzr-smart.py>
        PythonPath "sys.path+['/srv/example.com/scripts']"
        AddHandler python-program .py
        PythonHandler bzr-smart::handler
    </Files>
</Directory>

この設定は mod_python を通して /code 内部の /.bzr/smart で終わるURLに対するリクエストを Bazaar のスマートサーバーに渡すように指示します。

注: bzrlib が PATH の中に存在しない場合、次の行を変更する必要があります:

PythonPath "sys.path+['/srv/example.com/scripts']"

変更後は次のようになります:

PythonPath "['/path/to/bzr']+sys.path+['/srv/example.com/scripts']"

詳細な情報は mod_python のドキュメントを参照してください。

mod_wsgi¶

最初に、 a2enmod wsgi などで mod_wsgi を有効にしておきます。次に、 .bzr/smart で終わる全ての URL に対するリクエストを mod_wsgi 経由で処理するように設定します。設定例は次のようになります。

WSGIScriptAliasMatch ^/code/.*/\.bzr/smart$ /srv/example.com/scripts/bzr.wsgi

#The three next lines allow regular GETs to work too
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/code/.*/\.bzr/smart$
RewriteRule ^/code/(.*/\.bzr/.*)$ /srv/example.com/www/code/$1 [L]

<Directory /srv/example.com/www/code>
    WSGIApplicationGroup %{GLOBAL}
</Directory>

この設定では、 Apache は /code 以下の /.bzr/smart で終わる URL に対する全てのリクエストを WSGI 経由で Bazaar のスマートサーバーに渡し、それ以外の全てのリクエストは Apache が直接扱うようにしています。

詳細は mod_wsgi のドキュメントを参照してください。

Bazaarを設定する¶

FastCGI¶

/srv/example.com/scripts/bzr-smart.fcgi でスマートサーバーを実行するためにApacheを設定しました。これはスマートサーバーを設定するために書く必要のある単なるシンプルなスクリプトでサーバーをFastCGIのゲートウェイに結びつけます。次のようになります:

import fcgi
from bzrlib.transport.http import wsgi

smart_server_app = wsgi.make_app(
    root='/srv/example.com/www/code',
    prefix='/code/',
    path_var='REQUEST_URI',
    readonly=True,
    load_plugins=True,
    enable_logging=True)

fcgi.WSGIServer(smart_server_app).run()

　fcgi のモジュールはhttp://svn.saddi.com/py-lib/trunk/fcgi.pyで見つかります。これは flup の一部です。

mod_python¶

/srv/example.com/scripts/bzr-smart.py でスマートサーバーを実行するためにApacheを設定しました。これはスマートサーバーを設定するために書く必要のあるシンプルなスクリプトでサーバーをmod_pythonのゲートウェイに結びつけます。次のようになります:

import modpywsgi
from bzrlib.transport.http import wsgi

smart_server_app = wsgi.make_app(
    root='/srv/example.com/www/code',
    prefix='/code/',
    path_var='REQUEST_URI',
    readonly=True,
    load_plugins=True,
    enable_logging=True)

def handler(request):
    """Handle a single request."""
    wsgi_server = modpywsgi.WSGIServer(smart_server_app)
    return wsgi_server.run(request)

modpywsgi モジュールは http://ice.usq.edu.au/svn/ice/trunk/apps/ice-server/modpywsgi.py で見つかります。これは pocoo の一部でした。 modpywsgi.py を bzr-smart.py と同じディレクトリ (すなわち/srv/example.com/scripts/)に設置していることを確認してください。

mod_wsgi¶

We’ve configured Apache to run the smart server at /srv/example.com/scripts/bzr.wsgi. This is just a simple script we need to write to configure a smart server, and glue it to the WSGI gateway. Here’s what it looks like:

from bzrlib.transport.http import wsgi

def application(environ, start_response):
    app = wsgi.make_app(
        root="/srv/example.com/www/code/",
        prefix="/code",
        readonly=True,
        enable_logging=False)
    return app(environ, start_response)

クライアント¶

これで bzr+http:// 形式のURLやただの http:// のURLを利用できます:

bzr log bzr+http://example.com/code/my-branch

プレーンなHTTP形式のアクセスも持続します:

bzr log http://example.com/code/my-branch

高度な設定¶

BazaarのHTTPスマートサーバーはWSGIアプリケーションなので、 WSGI標準に準拠するサードパーティのWSGIのミドルウェアもしくはサーバーで利用できます。唯一の要件は以下のとおりです:

SmartWSGIApp をコンストラクトするためには、それが提供する root transport を指定する必要があります。

それぞれのリクエストの environ dict は ‘bzrlib.relpath’ 変数の設定を持たなければなりません。

この例で使われている make_app ヘルパーはそれに渡される root パスに基づいたトランスポートを伴う SmartWSGIApp をコンストラクトし、引数 prefix と`path_var` に基づくそれぞれのリクエストに対する　bzrlib.relpath を算出します。上記の例において、これは (Apacheによって設定される)’REQUEST_URI’ を取り、接頭辞の ‘/code/’ と接尾辞の ‘/.bzr/smart’ をはぎ取り、それを ‘bzrlib.relpath’ として設定するので、 ‘/code/foo/bar/.bzr/smart’ に対するリクエストは ‘foo/bzr’ の ‘bzrlib.relpath’ になります。

SmartWSGIApp を直接コンストラクトすることで、ローカルではないトランスポートに対してスマートサーバーを設定するもしくは任意任意のパスの変換を行うことは可能です。詳細な情報に関しては bzrlib.transport.http.wsgi のdocstringsと WSGI標準を参照してください。

HTTP スマートサーバー経由で push する¶

HTTP スマートサーバーを通してデータをプッシュすることは可能です。これを行うための最も簡単な方法は、 wsgi.make_app() コールに readonly=False を提供するだけです。ただし、スマートプロトコルは認証機能が含まれないので注意してください。書き込みのサポートを有効にする場合、実際にシステム上のデータを書き込みできる人を制限するために、 .bzr/smart URLへの権限を制限するとよいでしょう。例えば Apache で次のような設定をします。

<Location /code>
    AuthType Basic
    AuthName "example"
    AuthUserFile /srv/example.com/conf/auth.passwd
    <LimitExcept GET>
        Require valid-user
    </LimitExcept>
</Location>

現時点では、同じURLに対して読み込み限定の人と読み込みと書き込みの人を分けることはできません。 (認証を行う)HTTPレイヤーにおいて、すべては単なるPOSTリクエストだからです。しかしながら、HTTPSアクセスの場合に認証が必要な書き込みサーバーを使い、プレーンなHTTPは読み込み限定のアクセスを許可することはできます。

HTTPS サイトに対してアクセスしたときに bzr が次のようなエラーを表示する場合:

bzr: ERROR: Connection error: curl connection error (server certificate verification failed.
CAfile:/etc/ssl/certs/ca-certificates.crt CRLfile: none)

You can workaround it by using https+urllib rather than http in your URL, or by uninstalling pycurl. See bug 82086 for more details.

URL に https の代わりに https+urllib を使うことで問題を回避できます。詳細については bug 82086 を参照してください。

プラグインを書く¶

導入¶

プラグインはbzrのコア機能ととてもよく似ています。これらはbzrlibから何でもインポートできます。プラグインは標準機能を上書きすることもできますが、大抵プラグインは新しいコマンドを提供します。

新しいコマンドを作る¶

コマンドを書くには、 bzrlib.commands.Command を継承する新しいオブジェクトを作り、 cmd_foo と命名します。 fooはコマンドの名前です。名前にアンダースコアが含まれるコマンドを作ると、UIではアンダースコアはハイフンとして表示されます。たとえば、 cmd_baz_import は baz-import として表示されます。コマンドの書き方の実例に関しては、 builtins.py を参照して頂くようお願いします。

コマンドを作成したらファイルがインポートされるときに bzrlib.commands.register_command(cmd_foo) でコマンドを登録しなければなりません。さもなければbzrはコマンドを見つけることはありません。

フックをインストールする¶

Using hooks を参照してください。

プラグインのバージョン番号を指定する¶

プラグインのバージョン番号を定義するにはタプルで version_info を定義します。例： version_info = (0, 9, 0) version_info = (0, 9, 0, 'dev', 0)

プラグインの検索ルール¶

デフォルトではbzrはプラグインを見つけるために ~/.bazaar/plugins と bzrlib/plugins をスキャンします。 BZR_PLUGIN_PATH でこれを上書きできます。 (詳細は、ユーザーリファレンスを参照してください。)

プラグインはモジュールもしくはパッケージの形態をとることができます。プラグインが単独のファイルであれば、構造をモジュールにできます。プラグインが複数のファイルを持つ場合やbzrのブランチとして配布したい場合は、構造をパッケージ、すなわち、ディレクトリの中に __init__.py を含めます。

詳しい情報¶

他の人にも役立つと考えましたら、プラグインをBzrToolsにお気軽に寄付してください。

Bazaarの開発ガイドラインと方針の詳細に関しては Bazaar開発者ガイドを参照してください。

Licence¶

Copyright 2009-2011 Canonical Ltd. Bazaar is free software, and you may use, modify and redistribute both Bazaar and this document under the terms of the GNU General Public License version 2 or later. See <http://www.gnu.org/licenses/>.

Bazaar 2.0 移行ガイド¶

概要¶

移行手順の概要¶

Bazaar 2.xへのアップグレード作業は3段階あります:

コアソフトウェアの移行
必要なプラグインの移行
新しいデフォルトフォーマットへのデータ移行

Bazaar 2.xは以前のブランチのフォーマットをサポートしているので、厳密には3番目の手順は必要ありません。しかし、Bazaar 2.xの新しいデフォルトフォーマットはより効率よく領域を使用する、巨大なプロジェクトでより高速になる、さまざまな新しい特徴をそなえている、などの理由からほとんどのプロジェクトについて都合のよいときにでもアップグレードすることをおすすめします。

ほとんどのユーザの方は2.xへのアップグレードと新しいフォーマットへの移行に苦労しません。しかしながら、大勢の開発者がいる(もしくは多くの開発者をようする)プロジェクトでは移行作業に手間がかかります。この場合、注意深く計画をたてることとよいコミュニケーションが必要不可欠となります。本文書はこの視点からの一般的なアドバイスを記載しています。不安な点がありましたら、メーリングリストやIRCチャンネルで私たちにおたずねください。

コアソフトウェアの移行¶

コアソフトウェアの移行手順はオペレーティングシステムによって異なります。 Bazaar 1.xからBazaar 1.yへの移行とBazaar 1.xからBazaar 2.0への移行には特に違いはありません。手順の概要は以下のようになります。

Linuxでの移行手順:

必要なソフトウェアのソースに関してお使いのパッケージマネージャの設定をおこなう。

たとえばUbuntuの正式なリリースのPPAは https://launchpad.net/~bzr/+archive です。
パッケージマネージャを使用して最新バージョンに移行する。

Windowsでの移行手順:

「プログラムの追加と削除」で古いバージョンを削除する。
新しいバージョンのインストーラでインストールする。

OS Xでの移行手順(インストーラを使用):

新しいバージョンのインストーラでインストールする。

OS Xでの移行手順 (MacPortを使用):

package metadataを更新する。 sudo port selfupdate
最新のバージョンに更新する。 sudo port upgrade bzr

インストールや移行に関する詳しい情報については http://bazaar-vcs.org/Download をごらんください。

必要なプラグインの移行¶

多くのプラグインは特定のBazaarのバージョンに依存していないので、任意の作業です。他のプラグイン、特にbzrtoolsとbzr-svnはBazaarのAPIにかたく結びついているので、大体はコアソフトウェアとあわせて移行する必要があります。

WindowsやOS Xをお使いのかたは、bzrtoolsとbzr-svnはインストーラに付属していますので移行にあたって特別な作業は必要ありません。LinuxやUNIXをお使いのかたは、bzrtools、bzr-svn や他の著名なプラグインをインストールしたり移行作業をお使いのプラットホームのパッケージマネージャ (たとえばUbuntuのSynaptic)でおこなうことができます。

新しいデフォルトフォーマットへのデータ移行¶

冒頭でも説明しましたように新しいフォーマットへの移行に伴う複雑さはいくつかの要因、特にプロジェクトのコミュニティの大きさに依存します。また、データがどのように保存されているかにも依存します。たとえば standaloneブランチとか、複数のブランチがshared repositoryに格納されているかとか、Launchpad上の stackedブランチかなどです。これらのシナリオについては次章で説明します。

データ移行¶

データ移行の準備¶

移行を開始する前に、最初におこなうべきことがあります。

完全にバックアップをとってください。
古いブランチを消去(purge)する時間をとってください。

完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。

古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを `Finding obsolete branches`_ 　でご覧ください。

移行に関連するコマンドの紹介¶

データ移行時には注意すべき3つの重要なコマンドがあります。

check - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
reconcile - データ完全性に関するエラーの修復。
upgrade - 異なるデータフォーマットへの移行。

reconcile はめったに必要ではありませんが check を upgrade の前後で行うことは良い習慣です。

これらのコマンドの詳細なヘルプは Bazaarユーザーリファレンスをごらんください。

あなたのコミュニティとのコミュニケーション¶

新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:

trunkの移行を行う責任者を1人きめること。
trunkの移行試験が成功すること。
trunkを移行する時間の予定をたてることと、前もってあなたのコミュニティに知らせておくこと。

事前に警告をしておくことによりコミュニティに所属する人々が移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。

さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。

trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。

スタンドアロンブランチの移行¶

作業手順は以下のとおりです。:

bzr check を起動します。
もしエラーが発生したら、bzr reconcile を使ってエラーの修復をこころみてください。もしこれが失敗したら問題を解決してあなたのtrunkをクリーンにするために私たちがお手伝いできるようバグの報告ください。もし成功したならクリーンなtrunkなうちにバックアップをとってください。
bzr upgrade –format を実行してください。format は 2a またはそれ以降のことです。
bzr check を起動して最終結果が正しいかどうかを確認してください。

共用リポジトリ中のブランチを移行¶

移行は以下の手順で行ってください:

共用リポジトリの移行。
ブランチの移行。
軽量チェックアウトの移行。

スタンドアロンブランチの例のように check を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。

Launchpad上のブランチを移行¶

公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。

手順は次のようになります:

指名された人がtrunkのコピーを持ち移行作業を実施します。
Launchpadにおいては現在のtrunkを開発の中心(focus)からはずします。(これは必ず実施してください、そうしないとこの後の手順が期待通りになりません。)
移行した trunk をLaunchpadに push します。
開発の中心(focus)に設定します。
古い trunk に登録しているユーザに対して新しい trunk へ登録するよう依頼します。

つまり、これらの手順の意味は　古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。

この時点であなたはあなたのコミュニティに対して新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。

中央の trunk が移行した後のローカルブランチ移行¶

スタンドアロンブランチの移行手順:

中央リポジトリの場所から最新のブランチを新しいディレクトリに取得します。
既存のブランチの中のあなたが行った修正を新しいブランチへpullあるいはmergeします。

ブランチを共用リポジトリに移行する手順:

新しい共用リポジトリを新フォーマット(2aあるいはそれ以降)で作成します。
中央リポジトリから最新のブランチを作成した共用リポジトリへ格納します。
あなたのローカルブランチで移行したいものを決定します。 (もし決定していなければ、もちろんバックアップした後、 `Finding obsolete branches`_ をしてそのブランチを消去するのによい時間です。)
各ローカルブランチの移行に関して2つ選択肢があります。

新しいリポジトリで1つ空のブランチを init して古いリポジトリからリビジョンを pull する。

新リポジトリにおいて、 trunkから新しいブランチに branch した後古いリポジトリにおいてあなたが行った変更を merge する。

前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。

それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。

役立つヒントとコツ¶

古いブランチを見つける¶

もしあなたが開発における各変更や個々に行っている拡張のためにブランチの機能を使っている場合、いくつかのもう必要とされないブランチを持つことになるかもしれません。たいていの場合、関係のある変更は trunkにマージされているはずです。そのほかの場合ブランチは自分あるいは他人が行った別の変更の結果、古くなっているはずです。

古いブランチをチェックするときには特に3つの点に注意があります。

ワーキングツリーは変更の途中でないこと。
ワーキングツリー内にはbzr shelveコマンドによって退避された変更をふくんでいないこと。
どんなローカルでコミットされたリビジョンもparentブランチにマージされていること。

ブランチのルートディレクトリに移動したあと、これらの点を個々にチェックするためのコマンドは以下です:

bzr status
bzr shelve --list
bzr missing --mine-only

もしあなたのブランチがローカルの共用リポジトリに入っているならば、(revision 159またはそれ以降の)Bazaar Explorerのリポジトリビューの中の Local Changed タブがあなたが選択したブランチについて、いまのところはshelveコマンドによって退避された変更を除き、上記の情報の概要を表示するので有用です。

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

Version:	1.11
Generated:	2009-01-09

Contents

Bazaarユーザーリファレンス

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

このマニュアルはBazaarのオンラインヘルプから生成されました。オンラインヘルプのシステムを利用するためには次のコマンドを試してください。

よく使われるコマンドの一覧を含めて紹介します:
bzr help
トピックの一覧とそれぞれの要約:
bzr help topics
コマンドの一覧とそれぞれの要約:
bzr help commands
特定のトピックもしくはコマンドに関する詳細な情報:
bzr help topic-or-command-name

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

ホームページ:	http://www.bazaar-vcs.org/
公式ドキュメント:	http://doc.bazaar-vcs.org/
Launchpad:	https://launchpad.net/bzr/

概念 ¶

ブランチ¶

ブランチは、すべての履歴を含む、プロジェクトの状態で構成されます。すべてのブランチは関連づけされたリポジトリ(ブランチの履歴が保存される場所)を持ちますが、複数のブランチは同じリポジトリを共有することもあります(共用リポジトリ)。ブランチはコピーしたりマージしたりできます。

関連コマンド:

init    ディレクトリをバージョン管理されたブランチに変更する。
branch  ブランチの新しいコピーを作成する。
merge   3方向マージ (3-way merge) を実行する。

チェックアウト¶

チェックアウトはブランチに結びつけられたソースツリーなので、ソースツリーにコミットするときに、コミットの内容はブランチに格納されます。必要になるまでBazaarの分散型機能の一部を無視して、よりシンプルに、集中型のワークフローを利用できます。共用リポジトリでチェックアウトを利用することはSVNもしくはCVSでの作業とよく似ていますが、同じ制限を持ちません。そしてチェックアウトを利用することで望むワークフローがなんであれ他の人もプロジェクトに取り組むことができます。

チェックアウトはbzr checkoutコマンド(“help checkout”を参照)によって作成されます。これに別のブランチへのリファレンスを渡し、マスターブランチからのチェックアウトを作成したブランチへのリファレンスをまだ含むローカルコピーを作成します。

何かコミットをすればこれらは他のブランチで最初に作成されます。これによって作業内容のインスタントミラーが作成されるもしくはそれぞれの開発者が共同で作業して他の人の変更を継続的に統合するロックステップ開発を円滑にします。

しかしながらチェックアウトはまだBazaarの第一級のブランチで、すべての履歴をローカルで保存できます。第一級のブランチがあるので、ローカルにコミットすることもできます。たとえば、ネットワーク接続による一時的な遅延を回避したいのであれば、ローカルでもコミットできます。これを行うには –local オプションを使います。次にローカルではないコミットを行うときにすべてのローカルコミットはマスターブランチに行われます。

共用ブランチからのチェックアウトを使用しているとき、周期的に他の人による変更をすべてpullしたくなります。これは”update”コマンドによってできます。ローカルではないコミットの前に変更が適用される必要がありますが、 Bazaarは変更が存在することを伝え必要なときにこのコマンドを使うように提示します。

checkoutコマンドに–lightweightフラグを渡すことで”軽量”チェックアウトを作成することも可能です。第一級のブランチではなく、主に作業ツリーで構成されるという点で、軽量チェックアウトはSVNのチェックアウトにより近いです。履歴のオペレーションはマスターブランチに問い合わせをしなければならないので、ネットワーク接続が関わる場合遅くなる可能性があることを意味します。また、ローカルブランチを持たないので、ローカルでコミットできません。

マスターブランチに高速で信頼性のあるアクセス権限があるときに軽量チェックアウトは最も良く動作します。マスターブランチが同じディスクもしくはLAN上にあれば、(ブランチのコピーの更新だけが必要なので) リビジョンを変更するどのコマンドでも軽量ブランチは重量ブランチよりも速くなることを意味します。一般的に重量チェックアウトは速いですが、マスターブランチが同じディスク上のあるときは、顕著な違いはありません。

チェックアウトの別の使い方はブランチを格納するツリーなしのリポジトリで使うことです。ここでは異なるブランチに取り組むときチェックアウトが指定するマスターブランチを切り替えることで 1つの作業ツリーだけを維持します。

明確にチェックアウトにコミットするにはマスターブランチへの書き込み権限が必要です。マスターブランチはsftp://といった書き込み可能なプロトコルでアクセスしなければならないので、相手方で書き込み権限をもたなければならないことを意味します。チェックアウトはローカルファイルシステムでも機能するので、すべての問題はファイルのパーミッションです。

“bind”コマンド(“help bind”を参照)を使用することでチェックアウトのマスターを変更できます。これによってコミットが送信される位置が変更されます。 bindコマンドはブランチをheavyチェックアウトに変換するためにも使用できます。すべてのコミットがローカルで行われるようにheavyチェックアウトを通常のブランチに変換したい場合、 “unbind” コマンドを使用できます。

関連コマンド:

checkout    チェックアウトを作成する。軽量チェックアウトを得るには --lightweight を渡す
update      マスターブランチの変更をあなたのチェックアウトにpullする
commit      マスターブランチに送信されるコミットを行う。
            重量チェックアウトであれば --localオプションによって
            マスターにコミットを送信せずにチェックアウトにコミットされます
bind        送信されるチェックアウトにコミットされるマスターブランチを変更する
unbind      コミットがローカルだけで行われるように重量チェックアウトをスタンドアロンのブランチに変換する

クリスクロス¶

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

複雑なマージの場合、 bzr merge --lca もしくは bzr merge --weave ではよりよい結果になるかもしれません。作業ツリーを bzr revert して再度マージしたいと願うかもしれません。代わりに、特定の衝突しているファイル上で bzr remerge を使います。

2つのブランチが同じものをマージしてお互いにマージし合う場合、もしくは2つのブランチが同時にお互いをマージする場合、クリスクロスはブランチの中で発生します。それぞれのブランチが目的の集中型ブランチからもしくはそのブランチからのみマージすることでこれらを回避できます(“star topology”)。

マージが動作する方法のためクリスクロスは問題を引き起こします。 Bazaarのデフォルトマージは三方向マージです; OTHERをTHISにマージするには比較、BASE用の基本を見つけなければなりません。 BASEを利用することで、THISとOTHERの違いが行を追加するワンサイドか、行を削除する別のサイドによるのかを決定できます。

クリスクロスはベースに関してよい選択肢がないことを意味します。最近のマージポイントを選択することはワンサイドの変更を少し廃棄してしまう可能性があります。 (Bazaarが行う)古いマージポイントを選択することは余分な衝突が発せられることを意味します。

weave マージタイプはこの問題の影響を受けません。このタイプは違いの原因を決定するためにベースのリビジョンの代わりに行を起点とする検出方法を利用するからです。

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

古いクライアントが不正にデータにアクセスしないことを保証するために、 Bazaarのポリシーでは新しい機能が新しいメタデータを追加する必要があるときに新しいフォーマットを導入することにしています。新しいストレージフォーマットはパフォーマンスとスケーラビリティを改善するために導入することもあります。

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

既存のプロジェクトに取り組んでいる場合、プロジェクトが利用しているものを使用します。 (デフォルトでBazaarはあなたの代わりにこれを行います)。
Subversionリポジトリと連携するbzr-svnを利用している場合は、 1.9-rich-rootを使用します。
大きなツリー(5000以上のパス)もしくは深い履歴(5000以上のリビジョン)を持つプロジェクトに取り組んでいるのであれば、1.9を使用します。
さもなければ、デフォルトのフォーマットを使用します。大抵のプロジェクトはこれで十分です。

(ディストロのパッケージを利用しているなどで)最新のBazaarを利用できない開発者がいるのであれば、それに応じてガイドラインを調整してください。たとえば、プロジェクトがBazaar 1.7を標準化している場合、1.9の代わりに1.6を選ぶことが必要です。

注: 現在サポートされるフォーマットの多くは2つのバリアントを持ちます: plainのものとrich-rootのものです。後者はツリーのrootに関する追加フィールドを含みます。 rich-rootフォーマットを利用する際にパフォーマンスコストはありませんが rich-rootフォーマットからの変更をplainフォーマットに簡単にマージできません。結果として、すべての投稿者がほぼ同時にリポジトリをアップグレードする必要があるので、プロジェクトをrich-rootフォーマットに移行させるには調整が必要です。 (これまでのところrich-rootフォーマットをデフォルトにすることを遅らせてきた理由です。将来の適切な時期にこれを行います。)

現在サポートされるフォーマットの完全なリストに関しては bzr help current-formats を参照してください。利用可能で実験上もしくは廃止されたフォーマットに関しては bzr help other-formats を参照してください。

パターン¶

Bazaarはさまざまな時点でマッチするファイルを使用します。たとえば、 add コマンドは無視するパターンにマッチするファイルとスキップしプリファレンスはルールパターンを使用するファイルに関連づけできます。パターン構文は下記のとおりです。

パターン上のトレーリングスラッシュは無視されます。パターンがスラッシュを含むもしくは正規表現である場合、ブランチのroot全体から比較されます。さもなければ、これはパスの最後のコンポーネントのみと比較されます。 rootディレクトリの中のファイルのみにマッチさせるには’./’を用意します。絶対パスを指定するパターンは許可されていません。

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

? - '/'以外の単独文字にマッチする
* - '/'以外の0かそれ以上の文字数にマッチする
/**/ - パスの中のゼロかそれ以上のディレクトリにマッチする
[a-z] - 文字のグループの範囲内からの単独の文字にマッチする

パターンはPythonの正規表現にもなります。正規表現のパターンは ‘RE:’ の接頭辞で始まる正規表現で識別されます。正規表現のパターンは名前つきもしくは番号つきのグループを含むことはできません。

リポジトリ¶

Bazaarのリポジトリはコミットされた情報が保存される場所です。すべてのブランチと関連づけされたリポジトリが1つ存在します。

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

データベースのインデックスを最適化するようbzrに求めるとよいでしょう。これは’bzr pack’ コマンドによって行われます。

デフォルトでは ‘bzr init’ を実行するだけで新しいブランチの中でリポジトリが作成されますが、同じ位置で情報を共有するために複数のブランチを許可する共用リポジトリを作成することが可能です。新しいブランチが作成されたとき使用できる共用リポジトリが存在するかどうかを最初に確認します。

同じプロジェクトのブランチが1つのリポジトリを共有するとき、一般的にスペースが大きく節約されます。 (たとえばリポジトリの範囲内でブランチを作成するなどの)いくつかのコマンドに対してこれは大きな時間の節約になります。

共用リポジトリを作るには、init-repositoryコマンド(もしくはエイリアスのinit-repo)を使います。このコマンドは作成するリポジトリの位置をとります。このことは’bzr init-repository repo’によって’repo’という名前のディレクトリが作成されその中に共用リポジトリが格納されることを意味します。このディレクトリの中に作成された新しいブランチはストレージ用にそれを使用します。

1つ以上のプロジェクトのブランチを作成するときに1つのリポジトリを作成することはよい考えです。これは開発を行っている作業領域と、ホスティングプロジェクト用のサーバー領域の両方にあてはまります。後者の場合、作業ツリーなしのブランチが欲しいことは良くあります。ブランチのファイルは直接編集されないので作業ツリー用にディスクスペースを使い切る必要はありません。作業ブランチを持たないリポジトリを作成するには、 ‘init-repository’に’–no-trees’オプションを渡します。

関連コマンド:

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

ルール¶

紹介¶

ルールはiniファイルフォーマットで定義されます。セクションはファイルのglobパターンでそれぞれのセクションの内容はそのパターンにマッチするファイル用のプリファレンスです。例です:

[name *.bat]
eol = dos

[name *.html]
keywords = escape

これらのようなプリファレンスは選択されたブランチの中で選択されたファイル用にカスタムのふるまいを提供したいコマンドとプラグインに役立ちます。

ファイル¶

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

ルールのパターン¶

パターンは順序づけされ1つマッチすると共に検索は停止します。結果として、より明確なパターンをファイルのトップの方に置くべきです。ルールパターンは無視パターンとまったく同じ仕様を利用します。詳細は bzr help patterns を参照してください。

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

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

スタンドアロンのツリーは関連リポジトリを持つ作業ツリーです。他に依存していないので、これは独立して利用できるブランチです。 (bzr initを通して)スタンドアロンのツリーの作成は既存のプロジェクトをバージョン管理の元に置くための最も速い方法です。

関連コマンド:

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

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

チェックアウト、ツリーもしくはブランチを軽量ブランチに再設定するとき、ローカルのブランチを破壊しなければなりません。 (チェックアウトに関して、これはキャッシュとして最初に提供するローカルブランチです。) 破壊されるブランチが同じ最終リビジョンを持たなければ、軽量用チェックアウト用の新しい参照ブランチ、データが失われる可能性があるので、 Bazaarは拒否します。

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

チェックアウトが手元にありローカルコミットを行う場合、 “bzr update”(とおそらくは”bzr commit”)を実行することで再び同期化できます。

ブランチが手元にあり、リモートブランチが時代遅れになっている場合、 “bzr push”を使用してローカルの変更をプッシュできます。ローカルブランチが時代遅れであれば、”bzr pull”をできます。両方のブランチに変更があれば、変更をマージ、コミットしてプッシュできます。変更の一部が便利でなければ、”push –overwrite”もしくは代わりに”pull –overwrite”できます。

作業ツリー¶

作業ツリーはディスク上に設置されたブランチのコンテンツなのでファイルを見て編集できます。作業ツリーはブランチに変更を行う場所なので、作業ツリーの現在の状態をコミットするとき、コミットに記録されるレコードです。

ブランチをリモートシステムにプッシュするとき、作業ツリーは作成されません。ファイルがすでに存在すれば、ファイルは更新されません。ブランチの情報は更新され作業ツリーは時代遅れとしてマークされます。リモートの作業ツリーを更新するのは難しいです。アンコミットされた変更が存在するもしくは更新によってリモートで扱うのが難しい内容の衝突が引き起こされるからです。

作業ツリーなしのブランチがあれば作業ツリーを作成するために ‘checkout’ コマンドを使用できます。ブランチから ‘bzr checkout .’ を実行すると作業ツリーが作成されます。リモートでブランチが更新されると、そのディレクトリの中で’bzr update’を実行することで作業ツリーを更新できます。

望まない作業ツリーを持つブランチがある場合、安全であれば’remove-tree’コマンドはツリーを除外します。ブランチにプッシュするとき更新されないリモート作業ツリーに関する警告を回避することでこれは可能です。これは’–no-trees’リポジトリ(‘bzr help repositories’を参照)に取り組むときにも便利です。

プッシュするリモートマシン上で作業ブランチを持ちたい場合、 pushするごとにリモートブランチで’bzr update’を実行するか、 pushの間にツリーを更新する他の方法を使用できます。 rsyncを使用してpushと同じように作業ツリーを更新する’rspush’プラグインが存在します。それぞれのプッシュの後で’bzr update’を自動的に実行する’push-and-update’プラグインも存在します。

便利なコマンド:

checkout     ブランチが作業ツリーを持たないときにそれを作成する。
remove-tree  これを行うときに安全であるときにブランチから作業ツリーを除外する。
update       作業ツリーが関連ブランチから同期がずれているとき
             このコマンドによってブランチにマッチするツリーが更新される。

リスト ¶

認証の設定¶

Intent¶

authentication.conf ファイルの中で多くの異なる認証ポリシーは記述できますが特定のユーザーはすべてのブランチ用のユーザーとパスワードを指定しなくても自分のニーズをカバーするわずかな定義だけが必要です。

このファイルの中で見つかる定義は与えられたurl用のクレデンシャルを見つけるために使われます。一般的に同じクレデンシャルを必要とするリモートサーバーの周辺で宣言を分類することで可能な限り多くのブランチに対してクレデンシャルを使用できます。

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

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

このファイルの中で関連のクレデンシャルが宣言されるとパスワード(セキュリティハザード)を埋め込まずもしくは(他の人とURLの共有を有効にする)ユーザーなしでブランチのURLを利用できます。

次のURLよりも:

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

シンプルになります:

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

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

[myprojects]
scheme=ftp
host=host.com
user=joe
password=secret

認証の定義¶

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

ユーザーとパスワード

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

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

ホストに対して認証するために HTTP と HTTPS は(user, realm, password)を必要とします。 .htaccess ファイルを利用することで、たとえば、任意の host に対して (user, realm, password) をいくつか定義することが可能です。ですので本当に必要なのは (user, password, host, path)です。 realm は定義で考慮されませんが、bzrにパスワードを催促される場合表示されます。

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

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

scheme: 空にできます (定義の残りは任意のスキームに対して使用できることを意味する)、 SFTP と bzr+ssh はここでは使うべきではありません。代わりに ssh が使われるべきです。これが認証に関して本当のスキームだからです。

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

port は空にできます (ホストが同じスキームに対していくつかのサーバーを提供するときに便利)、数値の値のみが許可され、サーバーがスキームの標準ポートとは異なるポートを使用するときのみにこれは使用されます。

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

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

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

任意のURLに対して、複数の定義を提供できます。 bzrは次のルールに従って (user [, password]) を選択します:

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

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

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

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

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

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

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

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

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

セクションの名前は任意の文字列で、 DEFAULT の値のみが保存され最後のセクションとして現れます。

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

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

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

host: リモートサーバー
port: サーバーがリスンしているポート番号
path: ブランチの位置
password: パスワード

例¶

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

すべての接続は同じ user で行われ (デフォルトのbzrのものが適切でない場合のためのリモートの接続) パスワードはいくつかの例外とともに常に催促されます:

# hobby.netのPetプロジェクト
[hobby]
host=r.hobby.net
user=jim
password=obvious1234

# ホームサーバー
[home]
scheme=https
host=home.net
user=joe
password=1essobV10us

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

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

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

[shpnet domain]
# sftpを使用するが、sshは認証用に使用される
scheme=ssh
# '.' は 'shp.net' だけがマッチしないことを保証する
host=.shp.net
user=joe
# bzrはsftp用のパスワードの提供を保証しません
# パスワードをインタラクティブに入力したくなければ
# sshエージェントを使用することを考えてください(pageant, ssh-agent、など)

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

company.comにおいて、サーバーのホスティングリリースは統合ブランチの背後にはプロキシがあり、 2つのブランチは異なる認証ポリシーを使用します:

[reference code]
scheme=https
host=dev.company.com
path=/dev
user=user1
password=pass1

# devサーバー上の開発ブランチ
[dev]
scheme=ssh # bzr+sshとsftpはここで利用可能
host=dev.company.com
path=/dev/integration
user=user2

# プロキシ
[proxy]
scheme=http
host=proxy.company.com
port=3128
user=proxyuser1
password=proxypass1

計画的な強化¶

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

password_encoding フィールドの追加は次のとおりです:
- さまざまな難読化のエンコーディング(たとえばbase64)でパスワードを保存する。
- パスワードの保存をプラグインに委譲する(たとえば.netrc)。
ユーザーがユーザー名もしくはパスワードの入力を催促されたらクレデンシャルを更新する。
HTTPS 用に verify_certificates フィールドを追加する。

password_encoding と verify_certificates フィールドは認識されますが実際の実装では無視されます。

バグトラッカーの設定¶

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

Launchpadに加えて、BazaarはBugzillaとTracに適切なURLの生成を直接サポートします。プロジェクトが異なるバグトラッカーを使用するのであれば、そのサポートを追加するのは簡単です。 BugzillaもしくはTracを使用しているのであれば、バグトラッカーの基底URLを格納する設定変数を設定することだけが必要です。これらのオプションは bazaar.conf 、 branch.conf もしくは locations.conf のブランチ固有のセクションに入ります。取り組むプロジェクトごとにこれらの値をセットアップできます。

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

Launchpad¶

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

bugzilla_<tracker_abbreviation>_url¶

存在するのであれば、Bugzillaのバグトラッカーの位置は <tracker_abbreviation> によって参照されます。そのバグトラッカーのバグをそのコミットで修正されたものとしてマークするためにはこのオプションは bzr commit --fixes と一緒に使用できます:

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

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

trac_<tracker_abbrevation>_url¶

存在するのであれば、Tracインスタンスの位置は <tracker_abbreviation> によって参照されます。そのコミットによってバグが修正されたものとしてそのトラッカーの中でマークするためにこのオプションは bzr commit --fixes と一緒に使用できます:

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

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

bugtracker_<tracker_abbrevation>_url¶

存在するのであれば、一般的なバグトラッカーのインスタンスの位置は <tracker_abbreviation> によって参照されます。位置は {id} プレースホルダーを含まなければなりません。プレースホルダーは特定のバグIDに置き換えられます。そのコミットによってバグが修正されたものとしてそのトラッカーでマークするためにこのオプションを bzr commit --fixes と一緒に使用できます:

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

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

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

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

構成設定¶

環境変数の設定¶

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

BZR_EMAIL¶

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

"John Doe <jdoe@example.com>"

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

BZR_PROGRESS_BAR¶

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

BZR_SIGQUIT_PDB¶

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

0 = 標準のSIGQUITのふるまい(通常はコアダンプを伴ってexitする)
1 = ブレークインデバッガーを起動する (デフォルト)

BZR_HOME¶

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

BZR_SSH¶

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

BZR_PDB¶

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

0 = Standard behavior
1 = Launch debugger

BZR_REMOTE_PATH¶

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

設定値 bzr_remote_path も参照。

BZR_EDITOR¶

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

BZR_PLUGIN_PATH¶

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

BZRPATH¶

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

設定ファイル¶

設置場所¶

設定ファイルはLinux/Unixの場合 $HOME/.bazaar に Windowsの場合 C:\Documents and Settings\<username>\Application Data\Bazaar\2.0 に設置されます。 ( bzr version を使用することでシステムに設置された位置をチェックできます)

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

bazaar.conf はデフォルトの設定オプションを記述します
locations.conf は特定のブランチの位置用の設定情報を記述します。
authentication.conf はリモートサーバー用のクレデンシャル情報を記述します。

それぞれのブランチはそのブランチに固有な値を設定する設定ファイルも格納します。このファイルはブランチの範囲内の .bzr/branch/branch.conf で見つかります。このファイルはブランチのすべてのユーザーに見えます。あなたのブランチ専用に設定値の1つを上書きしたいのであれば、 locations.conf で行うことができます。

一般的なフォーマット¶

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

コメント¶

コメント行は “#” で始まります(“hash mark”, “pound sign” “number sign”とも呼ばれます)。コメント行はiniファイルを解析するときBazaarによって無視されます。

セクションヘッダー ^^^^^^^^^^^^^^^~~~~

セクションヘッダーは行頭から始まり角かっこで囲まれた単語です。典型的なセクションヘッダーは次のとおりです:

[DEFAULT]

bazaar.confに対して現時点で唯一有効なセクションヘッダーは[DEFAULT]と[ALIASES]です。セクションヘッダーは大文字と小文字を区別します。デフォルトのセクションが提供する設定変数はブランチの設定ファイルで上書きできます。

locations.conf に対して、セクションにマッチする最長のものを持つセクションからの変数は潜在的に有効な別のセクションヘッダーを除外するために使われます。セクションヘッダーはブランチ用のパスをセクションヘッダーとして使用します。次のような例があります:

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

セクション変数¶

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

email            = John Doe <jdoe@isp.com>
check_signatures = require

変数のポリシー¶

セクションの中で定義された変数は名前つきのディレクトリもしくはURLに加えてそれらを格納する位置にも影響を与えます。ポリシーは可変変数が含まれる位置のために解釈される方法を変更するために使用できます。現在は3つのポリシーが利用できます:

none:

値は含まれる位置に対して同じように解釈されます。これはデフォルトのふるまいです。

norecurse:

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

appendpath:

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

ポリシーは “$var:policy” 形式の名前を持つキーによって指定されます。たとえば、ブランチのツリー用のpushの位置を定義するには、次の設定が使われます:

[/top/location]
push_location = sftp://example.com/location
push_location:policy = appendpath

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

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

bazaar.conf は [DEFAULT] と呼ばれる1つのセクションだけを許可します。このデフォルトセクションはすべてのブランチ用のデフォルト設定オプションを格納します。デフォルトセクションは locations.conf にブランチ固有のセクションを提供することで上書きできます。

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

[DEFAULT]
email             = John Doe <jdoe@isp.com>
editor            = /usr/bin/vim
check_signatures  = check-available
create_signatures = when-required

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

locations.conf によって特定のブランチ用に設定を上書きできます。フォーマットは1つの重大な変更を伴うbazaar.confのデフォルトセクションに対してほとんど理想的です: デフォルトを記述する代わりに、セクションヘッダーは値を上書きしたいブランチへのパスになります。ワイルドカードの ‘?’ と ‘*’ がサポートされます:

[/home/jdoe/branches/nethack]
email = Nethack Admin <nethack@nethack.com>

[http://hypothetical.site.com/branches/devel-branch]
create_signatures = always
check_signatures  = always

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

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

authentication.conf によってリモートサーバー用のクレデンシャルを指定できます。これはすべてのサポートされる転送と認証(たとえばsmtp)を必要とするbzrの一部に対して使用できます。

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

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

変数の共通オプション¶

email¶

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

email = Full Name <account@hostname.tld>

editor¶

コミットメッセージなしで bzr commit が実行された場合に使用されるエディタのパスです。この設定は環境変数 BZR_EDITOR によって設定され、環境変数 VISUAL と EDITOR によって上書きされます。

check_signatures¶

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

require: リビジョン用のgnupg署名が存在して有効でなければなりません。
ignore: リビジョンのgnupgの署名をチェックしない。
check-available: (デフォルト) リビジョン用のgnupgの署名が存在する場合、それらをチェックします。わるい署名であることが分かるとBazaarは失敗しますが、署名が存在しない場合は失敗しません。

create_signatures¶

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

always: コミットされるすべての新しいリビジョンに署名する。
when-required: (デフォルト) ブランチが署名つきのリビジョンを要求するときのみ新しくコミットされたリビジョンに署名する。
never: ブランチが署名を要求する場合でも新しくコミットされたリビジョンに署名するのを拒否する。

recurse¶

locations.conf でのみ便利です。このセクション用の設定をサブディレクトリにも適用するかどうか定義します:

true: (デフォルトこのセクションはサブディレクトリにも適用される。
false: このセクションはこのディレクトリのブランチのみに適用されその下のブランチには適用されない。

gpg_signing_command¶

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

gpg_signing_command = /usr/bin/gnpg

bzr_remote_path¶

(デフォルト: “bzr”). bzr用のスマートサーバーを稼働させるために使われるコマンドへのパス。この値はlocations.confでのみ指定が許可されます。理由は次のとおりです:

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

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

smtp_server¶

(デフォルト: “localhost”)。たとえば merge-directive --mail-to 、もしくはbzr-emailプラグインによって BazaarがEメールを送信する必要があるときに使用するSMTPサーバー、

smtp_username, smtp_password¶

SMTPサーバーで認証するユーザーとパスワード。 smtp_usernameが設定されていて、smtp_passwordが設定されていなければ、Bazaarはパスワードを催促します。 Eメールを送信するためにSMTPサーバーが認証を必要とする場合のみこれらの設定が必要です。

mail_client¶

マージリクエストを送信するために使うメールクライアント。デフォルトでは、Windowsではbzrは mapi を使うことを試みます。他のプラットフォームでは、 xdg-email を試みます。これらのどちらかが失敗すると、 editor に戻ります。

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

claws:	Clawsを使用する。ファイル添付のダイアログはスキップする。
evolution:	Evolutionを使用する
kmail:	KMailを使用する
mutt:	Muttを使用する
thunderbird:	Mozilla ThunderbirdもしくはIcedoveを使用する。Thunderbird/Icedove 1.5に関して、これはxdg-emailが扱えないいくつかのバグに対処します。

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

default:	上記を参照。
editor:	マージリクエストを書くエディタを使用します。これはコミットID( `bzr whoami` を参照), smtp_serverと(オプションで)smtp_usernameとsmtp_passwordも使用します。
mapi:	Windowsで好きなメールクライアントを使用します。
xdg-email:	好きなメールプラグラムを実行するためにxdg-emailを使用する

submit_branch¶

現在の作業内容を投稿しようとしているブランチ。これは bzr send によって自動的に設定され submit: リビジョンスペックにも使用されます。通常、これはブランチ単位ロケーション単位で設定されます。

public_branch¶

このブランチの公開されアクセス可能なバージョン (このブランチが公開されてアクセス可能ではないことを暗示する)。 bzr send によって使用されます(そして設定されます)。

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

これらのオプションは dirstate-tags もしくは後のフォーマットを使用するブランチにのみ適用します。通常これらは自動的に .bzr/branch/branch.conf 設定されるもしくは手動で locations.conf もしくは bazaar.conf に設定されます。

append_revisions_only¶

“True”に設定されていればリビジョンはログにのみ追加され、削除されません。この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。通常これは bzr init --append-revisions-only によって設定されます。

parent_location¶

存在すれば、pullもしくはmerge用のデフォルトブランチの位置。通常このオプションは pull --remember もしくは merge --remember によって設定されます。

push_location¶

存在すれば、push用のデフォルトブランチの位置。通常このオプションは push --remember によって設定されます。

bound_location¶

チェックアウトとして振る舞うときコミットが向かう位置。通常このオプションは bind によって設定されます。

bound¶

“True”に設定されていると、ブランチはチェックアウトとしてふるまい、bound_locationにそれぞれのコミットをpushします。通常このオプションは bind/unbind に設定されます。

衝突のタイプ¶

オペレーションの中には、merge、revertとpullのように、作業ツリーの内容を修正するものがあります。これらの修正はプログラムで生成されるので、作業ツリーの現在の状態と衝突することがあります。多くの種類の変更はプログラムで結合できますが、正しいことを行われているか時々人間だけしか判断できないことがあります。これが起きるとき Bazaarはあなたに衝突が存在するのでそれを解消するように伝えます。 Bazaarに衝突が解消したことを伝えるコマンドは resolve ですが、これを実行できる前にいくつかのアクションを実行しなければなりません。

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

テキストの衝突¶

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

Text conflict in FILE

テキストのマージが2つのセットのテキストの変更を完全に折り合いをつけられないときにこれらは生み出されます。 BazaarはTHIS、OTHER、とBASEのエクステンションでそれぞれのバージョン用にファイルをemitします。 THISはターゲットツリーからのファイルのバージョン、すなわち、変更をマージしようとしているツリーです。 OTHERはターゲットにマージしようとしているバージョン、BASEは比較用のベースとして使われる古いバージョンです。

ファイルのメインコピーにおいて、Bazaarは調整できるすべての変更を含み、未調整の衝突は <<<<<<< のように “herringbone” マーカーによって囲まれます。

たとえば、初期のテキストが “The project leader released it.”、でTHISはこれを “Martin Pool released it.” に修正する一方で、 OTHERは”The project leader released Bazaar.”に修正します。衝突は次のようになります:

<<<<<<< TREE
Martin Pool released it.
=======
The project leader released Bazaar.
>>>>>>> MERGE-SOURCE

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

ファイルのメインコピーを編集する、もしくはTHIS、OTHERとBASEバージョン上で外部ツールを起動することのどちらかでテキストの衝突を扱うことができます。テキストの衝突の解消において他のものから変更のセットの1つの選別はめったにないことは言っておく価値があります。

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

メインコピーを編集するとき、 herringbone マーカーを必ず削除してください。編集作業を終えたとき、ファイルは衝突がけっして起こらないようであれば、コミットする準備ができています。

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

内容の衝突¶

典型的なメッセージ:

Contents conflict in FILE

ターゲットツリーとマージソースの中の変更の衝突が存在するときにこの衝突は起こりますが、が衝突したアイテムはテキストファイルではありません。これらはバイナリファイルもしくはシンボリックリンクもしくはディレクトリになります。片方が削除され、もう一方が修正されたファイルでも起こり得ます。

テキストの衝突のように、BazaarはTHIS、OTHER とBASEファイルをエミットしますが (これらは通常のファイル、シンボリックリンクもしくはディレクトリになります)、これはherringbone衝突マーカーを持つファイルの”メインコピー”を含みません。 “メインコピー”がTHISもくはOTHERにリネームされたときにこれは現れます。

これを解消するには、ファイルを通常の名前に戻すために “bzr mv” を使用し変更を手動で結合します。満足したときに、 “bzr resolve FILE” を実行します。この種の衝突が解消されたときにBazaarは自動検出できません。

重複したパス¶

典型的なメッセージ:

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

時々Bazaarはすでに使用されているパス名を用いてファイルを作成しようとします。既存のファイルは “FILE.moved” にリネームされます。望むのであれば、これらのファイルの1つをリネームするか、それらの内容を結合できます。満足したら、衝突を解消したものとしてマークするために “bzr resolve FILE” を実行できます。

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

典型的なメッセージ:

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

ときどきBazaarは親ディレクトリがバージョン管理されていないファイルを作成しようとします。ターゲットの中でディレクトリが削除されたときにこれが起こりますが、ソースの中の新しい子を持ちます。逆も同様です。この状況において、Bazaarは親ディレクトリも同様にバージョン管理します。この問題の解決方法は特定のシナリオに大きく依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとして”bzr resolve FILE”を実行できます。

見つからない親¶

典型的なメッセージ:

Conflict adding files to FILE.  Created directory.

ターゲットの中でファイルを削除するときにこれが起こりますが、ソースの中に新しい子があります。これは “unversioned parent” の衝突と似ています。バージョン管理を解除される代わりに、親ディレクトリが 存在しない ことを除いて、この状況において、Bazaarは見つからない親を作成します。この問題の解決方法は特定のシナリオに大いに依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとして “bzr resolve FILE” を実行できます。

親を削除する¶

典型的なメッセージ:

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

これは”見つからない親”の反対です。ソースの中でディレクトリは削除されますが、ターゲットの中で新しい子はあります。Bazaarはディレクトリを保有し続けます。この問題の解消は特定のシナリオに大いに依存します。ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。満足したら、衝突を解消したものとしてマークするために”bzr resolve FILE”を実行できます。

パスの衝突¶

典型的なメッセージ:

Path conflict: PATH1 / PATH2

ソースとターゲットがファイルの名前もしくは親ディレクトリを修正したときに起こります。 Bazaarはソースからパス要素を使用します。ファイルをリネームできれば、衝突を解消したものとしてマークするために “bzr resolve FILE” を実行します。

親のループ¶

典型的なメッセージ:

Conflict moving FILE into DIRECTORY.  Cancelled move.

ソースとターゲットがそれぞれディレクトリを移動させたので、変更が適用可能であれば、ディレクトリはそれ自身を含むときにこれは起こります。例です:

$ bzr init
$ bzr mkdir a
$ bzr mkdir b
$ bzr commit -m "BASE"
$ bzr branch . ../other
$ bzr mv a b
$ bzr commit -m "THIS"
$ bzr mv ../other/b ../other/a
$ bzr commit ../other -m "OTHER"
$ bzr merge ../other

この状況において、Bazaarは移動をキャンセルして、”a”を”b”の中に残しておきます。望むのであればディレクトリをリネームできれば衝突を解消したものとしてマークするために “bzr resolve FILE” を実行します。

ディレクトリではない親¶

典型的なメッセージ:

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

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

$ bzr init
$ bzr mkdir a
$ bzr commit -m "BASE"
$ bzr branch . ../other
$ rmdir a
$ touch a
$ bzr commit -m "THIS"
$ bzr mkdir ../other/a/b
$ bzr commit ../other -m "OTHER"
$ bzr merge ../other

MalformedTransform¶

Bazaarに例外のMalformedTransformを起動させること可能です(非常にまれですが)。これはBazaarが解決できないファイルシステムの衝突に遭遇したことを意味します。通常これはバグを示します。これに遭遇したら教えて頂くようお願いします。バグトラッカーは https://launchpad.net/bzr/+bugs です。

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

1.6.1-rich-root:
pack-0.92:	(ネイティブ) (デフォルト) 0.92で新しく導入: dirstate-tagsフォーマットリポジトリと互換性のあるデータを持つパックベースのフォーマット。 0.92以前のbzrリポジトリと相互運用できますが0.92以前のbzrでは読めません。以前はknitpack-experimentalと呼ばれていました。詳細な情報に関しては、 http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
1.6:	(ネイティブ) スタックをサポートするディレクトリに基づいたブランチとパック。
	(ネイティブ) スタックとリッチrootデータをサポートするブランチとパックベースのリポジトリ(bzr-svnが必要)
1.9:	(ネイティブ) btreeインデックスを使用するブランチとパックベースのリポジトリ。
1.9-rich-root:	(ネイティブ) btreeインデックスとrich rootデータを使用するブランチとパックベースのリポジトリ(bzr-svnに必要)。

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

環境変数¶

BZRPATH	bzrがシェルプラグインコマンドを探すパス。
BZR_EMAIL	ユーザーのEメールアドレス。EMAILを上書きする。
EMAIL	ユーザーのEメールアドレス。
BZR_EDITOR	コミットメッセージの編集用エディタ。EDITORを上書きする。
EDITOR	コミットメッセージの編集用エディタ
BZR_PLUGIN_PATH	bzrがプラグインを探すパス。
BZR_HOME	.bazaarの設定ディレクトリを保持するディレクトリ。HOMEを上書きする。
BZR_HOME (Win32)	bazaar設定ディレクトリを保持するディレクトリ。APPDATAとHOMEを上書きする。
BZR_REMOTE_PATH	リモート’bzr’コマンドのフルネーム(bzr+ssh:// URL用).
BZR_SSH	SSHクライアント: paramiko (デフォルト), openssh, ssh, plink.
BZR_LOG	.bzr.logの位置(ロギングを停止するには’/dev/null’を使う)。
BZR_LOG (Win32)	.bzr.logの位置(ロギングを停止するには’NUL’を使う)。

ファイル¶

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

ユーザーのデフォルト設定は上記のとおりです。 [DEFAULT] セクションすべての場所に適用される一般的な設定を定義するために使用できます。 [ALIASES] セクションは共通に使用されるオプション用のコマンドエイリアスを作成するために使用できます。

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

[DEFAULT]
email=John Doe <jdoe@isp.com>

[ALIASES]
commit = commit --strict
log10 = log --short -r -10..-1

グローバルオプション¶

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

`--version`	バージョン番号を表示する。コマンドの前に入力しなければならない。
`--no-aliases`	このコマンドを実行する際にコマンドエイリアスを処理しない。
`--builtin`	プラグインのコマンドではなく、組み込みのコマンドを使用する。このオプションは他のプラグインの効果を抑制しない。
`--no-plugins`	プラグインを処理しない。
`--profile`	ホットスポットプロファイラを使用するプロファイルの実行。
`--lsprof`	lsprofプロファイラを使用したプロファイルの実行。
`--lsprof-file`	lsprofプロファイラを使用するプロファイルを実行し、結果を指定ファイルに書き込む。ファイル名が”.txt”で終わる場合, テキストフォーマットが使用されます。ファイル名が”callgrind.out”で始まる、もしくは”.callgrind”で終わる場合、 KCacheGrind用に出力がフォーマットされる。さもなければ、出力はpickleになる。
`--coverage`	指定ディレクトリの行カバレージレポートを生成する。

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

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

フック¶

紹介¶

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

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

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

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

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

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

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

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

open (Branch)¶

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

post_push (Branch)¶

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

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

source_branch

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

target_branch

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

master_branch

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

local_branch

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

old_revno

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

old_revid

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

new_revno

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

new_revid

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

post_pull (Branch)¶

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

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

start_commit (MutableTree)¶

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

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

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

pre_commit (Branch)¶

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

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

post_commit (Branch)¶

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

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

post_uncommit (Branch)¶

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

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

pre_change_branch_tip (Branch)¶

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

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

branch

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

old_revno

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

old_revid

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

new_revno

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

new_revid

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

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

post_change_branch_tip (Branch)¶

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

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

branch

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

old_revno

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

old_revid

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

new_revno

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

new_revid

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

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

set_rh (Branch)¶

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

transform_fallback_location (Branch)¶

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

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

branch

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

url

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

(1.9の新しい機能)

server_started (SmartTCPServer)¶

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

backing_url

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

public_url

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

server_stopped (SmartTCPServer)¶

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

lock_acquired (LockDir)¶

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

lock_released (LockDir)¶

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

commit_message_template (msgeditor)¶

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

commit

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

start_message

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

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

(1.10の新しい機能)

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

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

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

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

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

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

リビジョンの識別子¶

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

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

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

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

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

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

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

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

標準オプション¶

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

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

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

ステータスフラグ¶

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

xxx   <filename>

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

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

カラム 2 - コンテンツ:

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

カラム 3 - 実行:

* 実行が少し変更された

URLの識別子¶

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

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

コマンド ¶

add¶

目的:

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

使い方:

bzr add [FILE…]

オプション:

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

説明:

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

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

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

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

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

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

関連コマンド:

remove

alias¶

目的:

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

使い方:

bzr alias [NAME]

オプション:

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

例:

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

bzr alias

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

bzr alias ll

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

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

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

bzr alias --remove ll

annotate¶

目的:

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

使い方:

bzr annotate FILENAME

オプション:

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

説明:

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

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

エイリアス:

ann, blame, praise

bind¶

目的:

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

使い方:

bzr bind [LOCATION]

オプション:

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

説明:

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

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

関連コマンド:

checkout, unbind

branch¶

目的:

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

使い方:

bzr branch FROM_LOCATION [TO_LOCATION]

オプション:

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

説明:

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

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

エイリアス:

get, clone

関連コマンド:

checkout

break-lock¶

目的:

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

使い方:

bzr break-lock [LOCATION]

オプション:

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

説明:

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

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

例:

bzr break-lock

cat¶

目的:

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

使い方:

bzr cat FILENAME

オプション:

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

説明:

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

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

関連コマンド:

ls

check¶

目的:

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

使い方:

bzr check [PATH]

オプション:

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

説明:

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

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

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

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

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

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

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

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

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

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

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

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

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

例:

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

bzr check --tree --branch foo

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

bzr check --repo bar

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

bzr check baz

関連コマンド:

reconcile

checkout¶

目的:

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

使い方:

bzr checkout [BRANCH_LOCATION] [TO_LOCATION]

オプション:

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

説明:

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

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

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

エイリアス:

co

関連コマンド:

branch, チェックアウト

commit¶

目的:

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

使い方:

bzr commit [SELECTED…]

オプション:

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

説明:

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

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

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

bzr commit foo -x foo/bar

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

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

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

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

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

エイリアス:

ci, checkin

関連コマンド:

bugs, uncommit

conflicts¶

目的:

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

使い方:

bzr conflicts

オプション:

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

説明:

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

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

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

関連コマンド:

resolve

deleted¶

目的:

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

使い方:

bzr deleted

オプション:

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

関連コマンド:

ls, status

diff¶

目的:

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

使い方:

bzr diff [FILE…]

オプション:

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

説明:

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

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

例:

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

bzr diff

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

bzr diff -r1

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

bzr diff -r1..2

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

bzr diff -r1..2 xxx

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

bzr diff NEWS

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

bzr diff xxx/NEWS

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

bzr diff –old xxx

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

bzr diff --old xxx --new yyy NEWS

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

bzr diff --prefix old/:new/

Exitの値:

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

エイリアス:

di, dif

関連コマンド:

status

export¶

目的:

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

使い方:

bzr export DEST [BRANCH_OR_SUBDIR]

オプション:

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

説明:

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

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

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

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

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

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

dir (none)

tar .tar

tbz2 .tar.bz2, .tbz2

tgz .tar.gz, .tgz

zip .zip

help¶

目的:

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

使い方:

bzr help [TOPIC]

オプション:

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

エイリアス:

?, –help, -?, -h

関連コマンド:

topics

ignore¶

目的:

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

使い方:

bzr ignore [NAME_PATTERN…]

オプション:

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

説明:

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

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

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

例:

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

bzr ignore ./Makefile

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

bzr ignore "*.class"

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

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

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

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

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

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

関連コマンド:

ignored, パターン, status

ignored¶

目的:

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

使い方:

bzr ignored

オプション:

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

説明:

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

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

bzr ls --ignored

関連コマンド:

ignore, ls

info¶

目的:

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

使い方:

bzr info [LOCATION]

オプション:

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

説明:

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

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

関連項目:

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

init¶

目的:

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

使い方:

bzr init [LOCATION]

オプション:

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

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

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

説明:

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

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

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

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

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

関連コマンド:

branch, checkout, init-repository

init-repository¶

目的:

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

使い方:

bzr init-repository LOCATION

オプション:

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

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

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

説明:

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

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

例:

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

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

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

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

エイリアス:

init-repo

関連項目:

branch, checkout, init, リポジトリ

log¶

目的:

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

使い方:

bzr log [LOCATION]

オプション:

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

ログのフォーマット::

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

説明:

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

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

例:

現在のブランチのログ:

bzr log

ファイルのログ:

bzr log foo.c

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

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

ls¶

目的:

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

使い方:

bzr ls [PATH]

オプション:

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

関連項目:

cat, status

merge¶

目的:

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

使い方:

bzr merge [LOCATION]

オプション:

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

マージアルゴリズム::

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

説明:

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

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

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

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

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

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

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

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

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

例:

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

bzr merge ../bzr.dev

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

bzr merge -r 82 ../bzr.dev

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

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

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

bzr merge /tmp/merge

関連項目:

remerge, status-flags, update

missing¶

目的:

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

使い方:

bzr missing [OTHER_BRANCH]

オプション:

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

ログフォーマット::

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

説明:

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

関連項目:

merge, pull

mkdir¶

目的:

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

使い方:

bzr mkdir DIR…

オプション:

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

説明:

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

mv¶

目的:

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

使い方:

bzr mv OLDNAME NEWNAME

bzr mv SOURCE… DESTINATION

オプション:

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

説明:

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

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

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

エイリアス:

move, rename

nick¶

目的:

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

使い方:

bzr nick [NICKNAME]

オプション:

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

説明:

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

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

関連コマンド:

info

pack¶

目的:

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

使い方:

bzr pack [BRANCH_OR_REPO]

オプション:

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

関連コマンド:

リポジトリ

plugins¶

目的:

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

使い方:

bzr plugins

オプション:

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

説明:

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

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

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

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

pull¶

目的:

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

使い方:

bzr pull [LOCATION]

オプション:

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

説明:

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

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

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

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

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

関連項目:

push, status-flags, update

push¶

目的:

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

使い方:

bzr push [LOCATION]

オプション:

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

説明:

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

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

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

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

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

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

関連項目:

pull, update, working-trees

reconcile¶

目的:

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

使い方:

bzr reconcile [BRANCH]

オプション:

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

説明:

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

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

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

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

関連項目:

check

reconfigure¶

目的:

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

使い方:

bzr reconfigure [LOCATION]

オプション:

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

Target type:

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

説明:

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

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

関連項目:

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

remerge¶

目的:

マージを再び行う。

使い方:

bzr remerge [FILE…]

オプション:

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

マージアルゴリズム:

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

説明:

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

例:

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

bzr remerge --show-base

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

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

remove¶

目的:

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

使い方:

bzr remove [FILE…]

オプション:

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

削除戦略:

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

説明:

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

エイリアス:

rm, del

remove-tree¶

目的:

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

使い方:

bzr remove-tree [LOCATION]

オプション:

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

説明:

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

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

関連項目:

checkout, working-trees

renames¶

目的:

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

使い方:

bzr renames [DIR]

オプション:

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

関連項目:

status

resolve¶

目的:

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

使い方:

bzr resolve [FILE…]

オプション:

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

説明:

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

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

関連コマンド:

bzr conflicts

エイリアス:

resolved

revert¶

目的:

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

使い方:

bzr revert [FILE…]

オプション:

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

説明:

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

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

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

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

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

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

関連項目:

cat, export

revno¶

目的:

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

使い方:

bzr revno [LOCATION]

オプション:

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

説明:

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

関連項目:

info

root¶

目的:

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

使い方:

bzr root [FILENAME]

オプション:

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

説明:

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

send¶

目的:

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

使い方:

bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]

オプション:

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

説明:

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

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

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

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

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

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

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

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

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

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

関連項目:

merge, pull

serve¶

目的:

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

使い方:

bzr serve

オプション:

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

エイリアス:

server

shelve¶

目的:

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

使い方:

bzr shelve [FILE…]

オプション:

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

writer:

--plain

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

説明:

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

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

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

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

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

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

関連項目:

unshelve

sign-my-commits¶

目的:

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

使い方:

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

オプション:

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

説明:

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

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

split¶

目的:

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

使い方:

bzr split TREE

オプション:

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

説明:

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

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

status¶

目的:

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

使い方:

bzr status [FILE…]

オプション:

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

説明:

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

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

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

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

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

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

エイリアス:

st, stat

関連項目:

diff, revert, status-flags

switch¶

目的:

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

使い方:

bzr switch TO_LOCATION

オプション:

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

説明:

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

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

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

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

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

tag¶

目的:

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

使い方:

bzr tag TAG_NAME

オプション:

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

説明:

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

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

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

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

関連項目:

commit, tags

tags¶

目的:

タグの一覧を表示する。

使い方:

bzr tags

オプション:

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

説明:

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

関連項目:

tag

testament¶

目的:

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

使い方:

bzr testament [BRANCH]

オプション:

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

unbind¶

目的:

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

使い方:

bzr unbind

オプション:

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

説明:

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

関連項目:

bind, チェックアウト

uncommit¶

目的:

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

使い方:

bzr uncommit [LOCATION]

オプション:

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

説明:

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

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

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

関連項目:

commit

unshelve¶

目的:

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

使い方Usage:

bzr unshelve [SHELF_ID]

オプション:

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

アクション:

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

説明:

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

関連項目:

shelve

update¶

目的:

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

使い方:

bzr update [DIR]

オプション:

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

説明:

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

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

エイリアス:

up

関連項目:

pull, status-flags, working-trees

upgrade¶

目的:

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

使い方:

bzr upgrade [URL]

オプション:

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

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

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

説明:

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

関連コマンド:

check

version¶

目的:

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

使い方:

bzr version

オプション:

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

version-info¶

目的:

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

使い方:

bzr version-info [LOCATION]

オプション:

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

フォーマット::

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

説明:

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

例:

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

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

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

{build_date} - 現在の日付

{revno} - リビジョン番号

{revision_id} - リビジョンid

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

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

whoami¶

目的:

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

使い方:

bzr whoami [NAME]

オプション:

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

例:

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

bzr whoami --email

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

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

ウェブリンク¶

切り替えガイド — 別のVCSツールから移ってきたユーザー用
移行ガイド — 別のVCSツールから履歴を移行するチーム用
用語
よく聞かれる質問

TortoiseBzrをインストールするには？¶

https://launchpad.net/bzr/+download からbzr-setup-x.xxx.exeを入手し、ファイルをダブルクリックをしてインストールウィザードを起動させます。その後の作業はインストールウィザードに従います。インストールウィザードが終了した後で再起動します。

もしPythonインタープリタにbzrをインストールした場合、インストールしたディレクトリによって bzr.exe(デフォルトでは C:\Program Files\Bazaar )よりもbzr.bat(C:\PythonXX\Scripts)が優先されるので、コマンドプロンプトでbzrと入力したときにbzr.exeが実行されるようにするには、 bzr.batをbzr.txtなどにリネームします。

カテゴリ	名前	説明
GUI	QBzr	QtベースのGUIツール
GUI	bzr-gtk	GTKベースのGUIツール
GUI	bzr-eclipse	Eclipseとの統合
General	bzrtools	その他。shelfを含めた機能の強化
General	difftools	外部の差分ツールヘルパー
General	extmerge	外部のマージツールヘルパー
Integration	bzr-svn	Subversionをリポジトリとして利用する
Migration	cvsps	CVSパッチセットを移行させる

Bazaarのメインドキュメント¶

目次¶

チュートリアル¶

5分でわかるBazaar¶

イントロダクション¶

インストール方法¶

まずは自己紹介¶

ファイルをバージョン管理する¶

ファイルを変更する¶

リビジョンのログを眺める¶

ブランチを Launchpad で公開する¶

別のブランチから自分用のコピーを作る¶

メインのブランチから自分のブランチを更新する¶

作業を親のブランチにマージする¶

さらに学ぶ¶

Licence¶

日本語訳について¶

Bazaar チュートリアル¶

はじめに¶

バージョン管理の目的¶

分散バージョン管理と分散でないバージョン管理の違い¶

Bazaarに自己紹介する¶

ブランチを作る¶

ブランチの場所¶

変更をレビューする¶

bzr status¶

bzr diff¶

変更をコミットする¶

bzr commit¶

エディタからメッセージを入力する¶

解決したバグの記録をつける¶

選択コミット¶

コミットされていない変更を削除する¶

ファイルを無視する¶

.bzrignore ファイル¶

bzr ignore¶

グローバルの無視設定¶

履歴を閲覧する¶

bzr log¶

ブランチの情報¶

ディレクトリをバージョン管理する¶

ファイルを削除する¶

ブランチを作る¶

上流の変更を追いかける¶

関連ブランチからマージする¶

ブランチを公開する¶

変更をツリー間で移動する¶

LaunchpadでBazaarを使う¶

動機付け¶

コミュニティはチームとは違う¶

協調開発に必要なもの¶

関係するコミュニティとの協調を助ける¶

Launchpad: 開発をもっと効果的に、摩擦は少なく¶

Bazaar: Launchpadのバージョン管理クライアント¶

Launchpadでのブランチの検索、閲覧¶

利用できるブランチの検索¶

ブランチの登録¶

ブランチの閲覧¶

Launchpad上のコードへのBazaarでのアクセス¶

プロジェクトのコードの取得¶

変更内容の公開¶

自分用のブランチ¶

パッケージのソースブランチ¶

Lanchpadでのブランチの関連づけ¶

ブランチをバグと関連付ける¶

BazaarでのコミットによるLaunchpadのステータスの変化¶

ブランチをブループリントと関連づける¶

Launchpadをつかったリリースの管理¶

変更内容の統合¶

ブランチのマージの提案¶

コードレビューの追跡¶

パーソナルパッケージアーカイブ(PPA)¶

翻訳¶

要約¶

集中型ワークフローのチュートリアル¶

概要¶

初期セットアップ¶

ユーザのEメールの設定¶

ローカルリポジトリのセットアップ¶

リモートリポジトリのセットアップ¶