Mercurial: "Collaborating with other people" を読む
Tagged:  •    •  

今回は "6. Collaborating with other people" を読みます。

6.1 Mercurial’s web interface

Mercurial には、 web 経由でのアクセスを提供するための、 スタンドアロン動作可能なサーバ機能が組み込まれています。

hg serve コマンドで簡単に起動できますから、 ちょっと触ってみるためだけに、 延々とウェブサーバの設定に付き合わされる心配はありません。

6.2 Collaboration models
6.2.1 Factors to keep in mind

「ルールは大事だが、 受け入れられて(= 遵守されて)初めて意味がある」のと、 「想定される問題には備えておきましょう」という話。

6.2.2 Informal anarchy

中・長期的な共有には向きませんが、 hg serve を使えば、 その場で簡単に作業成果を共有できます (要ネットワーク接続)。

6.2.3 A single central repository

成果物の共有用にリポジトリを用意し、 開発者は読み出し権限を、 管理者(ないしは、所謂「コミッター」)は読み書きの権限を持つ、 というモデルが、 最も簡単且つ基本的な開発体制のモデルです。

中央集約型の構成管理ツール(e.g.: CVS/Subversion)の場合、 全ての作業成果は共有リポジトリに集約される(= 集約せざるを得ない)のですが、 Mercurial の場合は、 共有リポジトリへの反映前であっても、 作業者の間で変更をやり取りすることが可能です。

6.2.4 Working with multiple branches

例えば「リリース」用のブランチを主とする共有リポジトリと、 「メイン開発」用のブランチ(= CVS で言うところのメイントランク) を主とするリポジトリを物理的に分離することにより:

  • 互いの成果を必要に応じて取り込むことは可能
  • 不要な変更を反映してしまう間違いを低減

というメリットを得ることができます。

6.2.5 Feature branches

大規模開発の場合のマスターへの反映は:

個人の作業用リポジトリ ⇒ 小規模チームの共有リポジトリ
                       ⇒ 中規模チームの共有リポジトリ
                       ⇒ ....
                       ⇒ 開発チーム全体の共有リポジトリ

というように多段的に行うことで、 他のコンポネント・機能部位の開発作業を相互に隔離しつつ、 成果物を共有することができます。

より上位の共有リポジトリへの反映(小規模⇒全体)や、 上位でのマージ結果の取り込み(全体⇒小規模)を、 品質監視を兼ねて構成管理担当者が行う、 という運用もアリでしょう。 むしろ、それだけの規模の開発の際に、 そういった役割に類する担当者を配備できないとしたら、 その時点でプロジェクトの行く末に一抹の不安がよぎります。

6.2.6 The release train

train という表現は、 「発車時刻に間に合ったものだけが乗車可能」 といったニュアンスのようですが、 これは一般的なのでしょうか?

6.2.7 The Linux kernel model

Linux カーネル開発において、 メインのソースリポジトリに変更が反映される仕組みについては、 他にも多くの文献・ウェブで語られていますね。

6.2.8 Pull-only versus shared-push collaboration

「分散リポジトリ形式のツールなら、 中央集約的に運用することも可能」という話。

6.2.9 Where collaboration meets branch management

このトピックの詳細は "Managing releases and branchy development" で扱っています。

6.3 The technical side of sharing

「残りの節は、トラブルシューティング関連」という話。

6.4 Informal sharing with “hg serve”

読み出し専用に限定されますが、 hg sreve を利用することで本当にあっと言う間にサーバを立ち上げることが出来ます。

6.4.1 A few things to keep in mind

hg sreve は:

  • 接続元ホストの制限
  • ユーザ認証

といったことを行いませんので、 不特定多数がアクセス可能な状況下で使用することはお薦めできません。

6.5 Using the Secure Shell (ssh) protocol
6.5.1 How to read and write ssh URLs

ここでは、 pull や push、incoming、outgoing における ssh アクセスの際に使用する ssh://[user@]host[:port]/[path] 形式のリポジトリ指定に関して説明しています。

6.5.2 Finding an ssh client for your system

O'Sullivan 氏お薦めの Windows 環境用 ssh クライアントは PuTTY のようです。

Linux や Unix 上で ssh を使い慣れている (あるいは今後併用する予定)なら、 個人的には Cygwin ssh がお勧めなのですが。

6.5.3 Generating a key pair

ssh-keygen~/.ssh/authorized_keys の話。

6.5.4 Using an authentication agent

ssh-agentssh-add の話。

Cygwin ssh を使用するなら、 win-ssh-agent を使わない手はありません。

6.5.5 Configuring the server side properly

「Mercurial を疑う前に、 まずは ssh でリモートホスト上でのコマンド実行ができるところまで確認してから」 という話。

リモートコマンド実行ができてしまえば概ね大丈夫だと思いますが、 対話的実行か否かで環境設定スクリプト起動の有無が変わる (例えば .bashrc.bash_profile.profile .login や、 /etc/bashrc による /etc/profile.d 配下の読み込み)ことから、 不意を突いて環境変数系の問題に足元を救われる場合があります。

そういう時に備えて、 ssh remotehost env などとやって、 ssh 実行時の環境変数一覧を確認しておくのが良いでしょう。

6.5.6 Using compression with ssh

ssh の圧縮指定は -C オプションか、 設定ファイルでの "Compression yes" 記述、 という話。

6.6 Serving over HTTP using CGI
6.6.1 Web server configuration checklist

「慣れていない人にとってはウェブサーバは大変」という話。

6.6.2 Basic CGI configuration

「慣れていない人にとっては CGI も大変」という話。

6.6.3 Sharing multiple repositories with one CGI script

「複数のリポジトリを公開するなら hgweb.cgi よりも hgwebdir.cgi」という話。

6.6.4 Downloading source archives

アーカイブファイルを事前に作っておかなくても、 (機能を有効化してあれば)自動的にアーカイブダウンロードができるようになる、 というのは便利ですね。

6.6.5 Web configuration options

「設定は適切なところで指定しましょう」という話。


後半は「Apache で始めるウェブサーバ構築」とか 「SSH で簡単セキュア接続」といった趣になっていますが、 やはり多くの人が陥りやすいポイントなのでしょうから、 しょうがないのでしょうね。


"Distributed revision control with Mercurial" 関連エントリの一覧は、BOSBook(Bryan O’Sullivan Book)タグで参照できます。