今回は、不安定な成果物が混在するメイン開発ラインに対して、リリース作業の構成管理の独立性・平行性を、分散リポジトリを使って確保する方法について説明します。一般的な開発の場合、以下のような契機での「リリース」が必要とされるのではないでしょうか。開発期間途中での中間納品こういった「リリース」の際、例えばCVSやSubversionといったモダンな構成管理ツールであれば、「⁠タグ付け」や「ブランチ」といった機能により、以下のようなことを実現します(体系的な詳細に関しては、「⁠パターンによるソフトウェア構成管理」を参照されるのが良いでしょう⁠)⁠。継続的な保守しかし、中央集約リポジトリ形式の構成管理ツールの場合、「⁠メイン開発」と「リリース作業」のブランチが物理的に同一のリポジトリで運用されるため、不注意や誤操作、運用上の問題による両者間での予期せぬ成果の混交、といった問題には決定的な対応策がありません。(⁠必要であればもっと多くの)用途向けに、物理的に異なるリポジトリを用意することで、両者間での作業成果の混交を容易に回避することができます。共有リポジトリの立ち上げ「メイン開発」と「リリース作業」の2つにリポジトリを分離する前に、まずは「メイン開発」用の共有リポジトリを立ち上げましょう。「メイン開発」用の共有リポジトリは、以下の方針で運用するものとして説明を進めます。リポジトリはメンバーで共有可能なUNIX系サーバ上で運用(以下"host")開発用にプロジェクトアカウントを用意(以下"proj")"~proj"配下にリポジトリを作成(以下"~proj/hgrepo/dev")メンバーはsshでリポジトリにアクセス共有サーバの用意や、projアカウントの作成などは、各自の環境におけるシステム管理担当に依頼してください。init"コマンドを使用します。initproj@host%各メンバーのsshによるアクセスに関しては、以下のような設定にするのが一般的と思われます。専用グループを作成(以下"proj")"proj"アカウントのプライマリグループは"proj""~proj"配下はグループ書き込み可能にメンバーを"proj"グループに所属メンバーは自身のアカウントでsshログインしかし、この方法には幾つかの問題点があります。umask設定による書き込み権限のマスク:「プロジェクト遂行以外の用途でのサーバアクセスは無い」と断言できる場合は別ですが、メンバーの個人設定はumaskが022、即ち「自分以外の書き込み禁止」以上の強度に設定するのが一般的です。別なメンバーは同じファイルに対して書き込みができなくなってしまいます。NFS併用時のグループ所属上限:NFSを併用する環境では、ユーザが16以上のグループに属する場合に、権限判定が適切に行われません。これはNFSプロトコル仕様上の制約であるため、実行時に設定ファイル記述等で回避できる類のものではありません。(⁠公開鍵によるアクセス制御等も容易ですし⁠)⁠。clone"が可能です。clone"の引数に指定する対象リポジトリは、以下のように変更する必要があります。3ssh://myaccount@host//home/proj/hgrepo/dev上記例では"~proj"の絶対パスを"/home/proj"と仮定しています。ホスト名の後ろの"//"は、パス指定が絶対パスであることを意味しています。あるのかを切り分けましょう(各自のアカウントでアクセスする場合は、"proj"部分を各自のアカウントに変更してください⁠)⁠。clone"の失敗原因がある程度絞り込めます。help"実行が成功:リポジトリの位置指定が間違っているか、リポジトリ(あるいはそこに至るディレクトリ)のアクセス権限設定が不適切である可能性が考えられます。PYTHONPATH設定が不適切でMercurialのモジュールがロードできない可能性が考えられます。対話的なログイン時と、非対話的なログインでは、読み込まれる設定ファイルが異なる場合がありますので、sshでenvコマンドを実行することで、環境変数設定を確認してみてください。sshの実行そのものが失敗:各自の環境のssh設定を見直してください。以上で共有リポジトリの立ち上げは完了です。push"も可能です。「リリース作業」用リポジトリの分離それではいよいよ「リリース作業」用のリポジトリを、「⁠メイン開発」用のリポジトリから分離しましょう。「リリース作業」用の共用リポジトリは、以下の方針で運用するものとして説明を進めます。運用するサーバは「メイン開発」用と同じ("host")アカウントは「メイン開発」用と同じ("proj")"~proj"配下にリポジトリを作成(以下"~proj/hgrepo/release")メンバーはsshでリポジトリにアクセスベースとする版のチェンジセットハッシュ値は"123456789abc"1~4までは、「メイン開発」用の共有リポジトリ立ち上げの際と同じ手順で実施してください。「リリース作業」リポジトリでは、特定の版を元に作業することになりますので、以下のようにして必要な成果を「メイン開発」リポジトリから取り込みます。~/hgrepo/dev....proj@host%以上で、host上の"~proj/hgrepo/releasse"には、"123456789abc"を最新とする成果物が格納されました(厳密な話をするなら、単に"123456789abc"を指定した場合、「⁠リリース作業」にとって不要なチェンジセットも含まれ得ますので、その場合はもう少し細かくチェンジセットを取り込む必要があります⁠)⁠。後は、リリース作業担当者に、"ssh://proj@host/hgrepo/release"から"hgclone"して作業するようにアナウンスすれば良いでしょう。"~proj/hgrepo/release"リポジトリは、第1回でも説明したように、元となっている"~proj/hgrepo/dev"とは独立して機能しますから、意図的な操作をしない限り、「⁠メイン開発」と「リリース作業」間での成果の混交は回避されます。先の説明で例示した「リリース作業」リポジトリの運用方針は、「⁠メイン開発」の運用方針のうち、リポジトリの格納されるパスを少々変更しただけの簡単なものです。通常はこれでも十分だと思われますが、作業成果の隔離度合いを更に強化する場合、幾つかの方法が考えられます。明確な悪意を持ったアクセスでも無い限り、「⁠メイン開発」から「リリース作業」への成果物の混入は、ほぼ皆無にできるのではないでしょうか。~/hgrepo/dev....proj@host%他にも以下のような隔離方法が考えられます。「リリース」で全く何も変更が無い事もあるでしょうが、「⁠リリース」が完了した際には、そこでの固有成果物の「メイン開発」への統合、即ちマージが必要になります。日常的に実施しているマージとさほど違いがあるわけではありません。push"以上で終わりです。「⁠リリース」後のマージなお、マージ担当者が混乱しないためにも、「⁠メイン開発」「⁠リリース作業」の共有リポジトリのそれぞれを、常に枝分かれが無い状態に保つことは非常に重要です。以下のような警告が表示されて処理が中断されますから、"pull"⇒"merge"⇒"commit"⇒"push"の手順さえ守っていれば、通常は枝分かれすることはありません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。