一般的なレイアウト

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

この後の、変更を行ったりその変更を公開して適用してもらうまでのプロセスは機能ブランチレイアウトの時と同じです。

進んだレイアウト

お望みとあれば、あなたのお好みの構成に合わせてレイアウトを決めることができます。 例やアイデアについては 共有リポジトリのレイアウト を参照してください。