「入門TortoiseHg＋Mercurial」発売中（詳細は「執筆情報」参照）
| MAP | TOP > 工房「藤車」 > SCM メモ > Mercurial の利用 > システム構成例 | << | >> |
本節では、 Mercurial では実現できても、 CVS （あるいは他の集中リポジトリ型の SCM ツール） を利用した場合には実現が難しい（あるいは運用が面倒な） 構成管理のシステム構成例を示します。
特定のソフトウェア／ハードウェアの必要性や、 インフラ等の利便性の面などから、 ファイルの編集やコンパイル確認を行う主開発環境と、 実際に動作させる（あるいは性能計測等の検証を行う）環境が異なる。
開発者間での共有用リポジトリへの更新伝播前に、 検証用環境で確認を行いたい。
共有リポジトリ(Master)／開発者リポジトリ(Worker)の他に、 検証環境にも各開発者ごとのリポジトリ(Examiner)を用意し、 事前検証および検証結果による作業成果の取り込みは、 開発者リポジトリ／検証環境リポジトリ間での更新伝播で実現する。
他の開発者の成果物とのマージ作業は、 開発者リポジトリで行う。
共有リポジトリにコミットすること無しに、 開発環境／検証環境間で作業成果の受け渡しを行うには、 (1)ワーキングコピーを丸ごとコピーする（⇒ 転送量が増える）か、 (2)差分をやり取りする （⇒ 検証環境／開発環境間でのやり取りの際に取りこぼしが有り得る） 必要がある。
例えば、 開発者 A 用の Worker において最新の Master からの複製および変更実施を行い、 その成果を元に Examiner で更に補正作業を行います。
開発者 A は Examiner での成果の Worker への取り込みに加えて、 Master に対する更新伝播も行いますが、 他の開発者の成果が既に Master に伝播している場合、 自身の成果物とのマージを行う必要があるため、 まずは Master から他の開発者の成果を取得します。
開発者 A は他の開発者と自身の成果のマージを行った後に、 Master に更新伝播を行います。 今度は、他の開発者が A の（マージ結果の）成果を取り込みます。
Master への更新伝播の前に Examiner での再検証が必要なマージ内容の場合は、 上記の手順を繰り返すことになります。
複数の開発拠点（e.g.: チーム／部署／協力会社）ごとに、 比較的独立した開発作業が行われている
拠点ごとの開発成果は、 受け入れ試験を実施してから全体で共有したい
各開発者は、開発者毎リポジトリ(Worker)と拠点毎リポジトリ(Division) との間で更新伝播を行う。
受け入れ試験担当は、 各拠点毎リポジトリの内容を元に受け入れ試験を行い、 成果物が受け入れ可能な水準であれば、 集約用リポジトリ(Master)に更新を伝播する。
構成管理責任者は、 拠点毎の成果を集約用リポジトリ上でマージし、 各拠点毎リポジトリへ集約結果の更新伝播を行う。
成果の集約および伝播を行うには、 (1)拠点ごとのブランチを定義する （⇒ 全体での集約結果の伝播 ＝ 逆マージが面倒）か、 (2)各拠点ごとに個別のリポジトリを作成 （⇒ リポジトリ間でのコピーの際に構成管理情報が失われてしまう） する必要がある
各拠点では、 Division に複製した Master の内容を元に開発作業を行い、 Worker での成果を Division へと集約します。 Division と Worker の間では、 拠点内の成果共有／マージのために、 頻繁に更新伝播が行われます。
各拠点ごとの成果は、 受け入れ試験担当者による受け入れ試験完了後に Master に集約されます。
Master に集約された各 Division での成果は、 構成管理責任者により適宜マージ作業が行われ、 その結果が各 Division へと反映されます。
各拠点の作業者は、 Master から Division への更新伝播を自身の Worker に反映し、 引き続き開発作業を継続します。
上記手順において、 全ての更新の実施者／時刻／内容の記録がそのまま Master に伝播されているため、 構成変更の追跡可能性が損なわれることはありません。 また、受け入れ条件を満たさない成果物が、 Master を経由して他の Division に伝播することも （受け入れ試験が適切に運用されていれば） ありません。
| MAP | TOP > 工房「藤車」 > SCM メモ > Mercurial の利用 > システム構成例 | << | >> |