今回は，普段使用している共有リポジトリ（＝ マスターリポジトリ）へのアクセスができないような，制約のある状況を考えてみます。このような状況でも，分散リポジトリ形式であることを活かし，共同作業を円滑に進める方法について説明します。
「閉じた環境」での作業
開発成果をリリースする場合，顧客の環境に赴いての導入作業や，場合によっては稼動環境下での障害調査・対応が求められるケースがあります。
ある程度の規模の組織では，システム稼働環境は無論のこと，作業用PCが接続されたネットワークですら，ファイアーウォールや運用規約によって，ガッチリと守られている場合の方が多いのではないでしょうか。
そういった環境には，当然外部からアクセスすることはできませんから，アクセスするためにはターゲット環境側に移動する必要がありますが，今度は逆にマスターリポジトリへのアクセスができなくなってしまいます。
そうなると，中央集約形式リポジトリを用いるCVSやSubversionなどは，更新内容の記録どころか，これまでの作業記録を参照することすらできません。
図1 閉じた環境での作業
筆者は以前，このような状況で複数メンバーでの作業が必要になった際に，以下のような方法で強引に乗り切ったことがあります。
- Linuxを稼動させる小型PC（以下「dejima」）を用意
- dejima上で新規にCVSリポジトリ（以下「submaster」）を作成
- マスターリポジトリの最新成果をsubmasterにimport
- dejimaをターゲット環境に持参
- 作業内容はdejima上のsubmasterで記録
- ターゲット環境からdejimaを引き上げ
- submasterの最新状態をマスターリポジトリに反映
図2 臨時リポジトリでの作業
しかし，この方法の場合，マスターリポジトリへの反映の際に，ターゲット環境での作業記録が一切合財失われてしまいます。 Subversion なら，チェンジセット単位でのマスターリポジトリ反映により記録を保つことも可能ですが，面倒な作業になることは想像に難くありません。
また，submasterへの取り込みは，あくまで最新成果のみですから，これまでの作業履歴を参照するようなことはできません。
Mercurialのような分散形式リポジトリの場合，そもそも「マスターリポジトリ」という考え方が，運用上の相対的なものですので，このようなケースでも普段の使い勝手を落とす事無く使用することができます。
