.. _organizing-your-workspace:

作業スペースを構成する
=========================

.. _common-workspace-layouts:

一般的なレイアウト
---------------------

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に比べてスマートです。
チェックアウトはまずリモートにコミットして、それが成功したときにだけ\
ローカルにもコミットします。

.. _feature-branches:

機能ブランチ
--------------

このレイアウトでは、いくつかのブランチとツリーがあって、一般的にリポジトリを共有します。
一つのブランチは "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などのゲートキーパー型のワークフロー\
を利用していたときに有用です。


.. _local-sandbox:

ローカルの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

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


進んだレイアウト
----------------

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