第4回　誰でも「マスターリポジトリ」～リポジトリ連携の相対性

今回は、普段使用している共有リポジトリ（＝マスターリポジトリ）へのアクセスができないような、制約のある状況を考えてみます。このような状況でも、分散リポジトリ形式であることを活かし、共同作業を円滑に進める方法について説明します。

「閉じた環境」での作業

開発成果をリリースする場合、顧客の環境に赴いての導入作業や、場合によっては稼動環境下での障害調査・対応が求められるケースがあります。

ある程度の規模の組織では、システム稼働環境は無論のこと、作業用PCが接続されたネットワークですら、ファイアーウォールや運用規約によって、ガッチリと守られている場合の方が多いのではないでしょうか。

そういった環境には、当然外部からアクセスすることはできませんから、アクセスするためにはターゲット環境側に移動する必要がありますが、今度は逆にマスターリポジトリへのアクセスができなくなってしまいます。

そうなると、中央集約形式リポジトリを用いるCVSやSubversionなどは、更新内容の記録どころか、これまでの作業記録を参照することすらできません。

筆者は以前、このような状況で複数メンバーでの作業が必要になった際に、以下のような方法で強引に乗り切ったことがあります。

Linuxを稼動させる小型PC（以下「dejima⁠」⁠）を用意
dejima上で新規にCVSリポジトリ（以下「submaster⁠」⁠）を作成
マスターリポジトリの最新成果をsubmasterにimport
dejimaをターゲット環境に持参
作業内容はdejima上のsubmasterで記録
ターゲット環境からdejimaを引き上げ
submasterの最新状態をマスターリポジトリに反映

しかし、この方法の場合、マスターリポジトリへの反映の際に、ターゲット環境での作業記録が一切合財失われてしまいます。 Subversion なら、チェンジセット単位でのマスターリポジトリ反映により記録を保つことも可能ですが、面倒な作業になることは想像に難くありません。

また、submasterへの取り込みは、あくまで最新成果のみですから、これまでの作業履歴を参照するようなことはできません。

Mercurialのような分散形式リポジトリの場合、そもそも「マスターリポジトリ」という考え方が、運用上の相対的なものですので、このようなケースでも普段の使い勝手を落とす事無く使用することができます。

相互連携による成果の共有

今時のセキュリティ基準からすると、幾分「ゆるめ」ではありますが、以下の環境下での作業を念頭に説明を進めたいと思います。

複数人で作業
各自の作業用ノートPCは持ち込み可能
ノートPC同士はLAN環境で相互接続可能
LANから外部への接続は不可

この条件での作業は、「⁠客先への出向」以外にも、「⁠OSSのオフラインミーティング・勉強会」といったシチュエーションにも当てはまることが多いのではないでしょうか。

ローカルリポジトリの公開

Mercurialはリポジトリの公開方法を複数提供していますが、その中でも今回説明するシチュエーションにふさわしいのは、"hg serve"による簡易サーバ機能です。

リポジトリ（のワーキングディレクトリ領域）に移動し、"hg serve"コマンドを実行してください。

コマンド 1

% hg serve

何も応答がなくなりますが、心配する必要はありません。

ウェブブラウザを起動し、localhost（または127.0.0.1）の8000 番ポートにアクセスしてみてください（"http://localhsot:8000/"⁠）⁠。以下のようなリポジトリ情報が表示されるはずです。

さらに、"hg serve"で起動された「リポジトリサーバ」経由で、"hg clone"によるリポジトリの複製をしてみましょう。

コマンド 2

% hg clone http://localhost:8000/
....
%

成果の共有

各自の作業用ノートPCで"hg serve"の稼動が確認できたなら、自分のノートPCのIPアドレスを教えれば準備は完了です。

各自が個別に作業しつつ、ある程度成果がたまるたびに、お互いに"hg pull"することで、各自のノートPC上の"hg serve"が稼動しているリポジトリへの更新を、メンバーの間で流通させることができます（設定変更により、"hg serve"に対する"hg push"を許可することもできます⁠）⁠。

共有リポジトリが無い状態でお互いの成果を1つにマージするには、多少の工夫が必要です。

例えば、マージ担当者を一人決め、
(1) 担当者がメンバー全員の成果を "hg pull" し、
(2) マージした後に、
(3) 他のメンバーが担当者のリポジトリから "hg pull" することで、全員の成果をマージできます（矢印の向きはデータの流れ⁠）⁠。

あるいは、順繰りに"pull"＋"merge"を繰り返した後で、最後のメンバーのリポジトリから、他のメンバーが"hg pull"するのも良いでしょう。

マスターリポジトリへの成果の反映

開発用のマスターリポジトリにアクセス可能な状態になったなら、それまでの作業成果を反映させましょう。

とは言っても、何も特別なことは必要ありません。

作業成果が多ければ、普段のマージよりは衝突の可能性が高いかもしれませんが、せいぜいが「リリース」後の成果統合程度の作業です。

push/pull のパズル

今回の冒頭でも述べましたが、Mercurialのような分散形式リポジトリの場合、そもそも「マスターリポジトリ」という考え方が、運用上の相対的なものです。

「たった今から、こちらがマスターリポジトリ」という決定に、メンバーが従うならば、それまでのマスターリポジトリは、その瞬間から最早マスターリポジトリではなくなるのです。

第3回で紹介した、リリース時作業専用リポジトリを作成する手法も、言ってみれば「期間・対象メンバー限定の臨時マスターリポジトリ」と言えるでしょう。

それと同様に、push/pull の関係も相対的なものです。

Mercurialを使い始めの頃は、「⁠成果を集積する側に近い方（＝上流⁠）⁠」と、「⁠実際に作業する側に近い方（＝下流⁠）⁠」の関係に囚われて、「⁠push/pull は下流から上流に対して実施するもの」と思い込みがちです。

しかし、「⁠AからBに対するpush要求」と、「⁠BからAに対するpull要求」の間には、成果伝播上は何ら違いはありません。単に「要求の発行方向」と「構成管理差分情報の伝播方向」が一致するか否かだけの違いです。

「push/pull のパズル」を解く様な気持ちで見直してみると、制約のある環境での利用であっても、リポジトリ間で上手く成果を伝播させる方法が見つかるのではないでしょか。