Mercurial を理解する

新規ユーザは Mercurial の分散開発モデルに混乱するかもしれません。このページでは、いくつかの基本概念を解説しようと思います。 順を追った説明は チュートリアル を参照してください。

1. リポジトリにあるもの

Mercurial の リポジトリ には store と連動した 作業ディレクトリ があります:

store は、プロジェクトの完全な履歴を格納しています。唯一中央にのみ履歴のコピーを持つ旧来の SCM 類と異なり、全ての作業領域ディレクトリは、履歴のプライベートなコピーを持っています。これにより、開発を並列に行うことが出来ます。

作業領域ディレクトリは、指定された時点 (例えば rev 2) におけるプロジェクトファイルのコピーを持っており、それらを編集することが出来ます。タグ や 無視するファイル に関する設定もリビジョン管理されているので、それらの情報も含まれています。

2. 変更のコミット

コミット の際には、 parent (親) に対する作業ディレクトリの状態が、新しい チェンジセット として記録されます。(新しい "リビジョン" とも言います):

rev 4 は、作業領域ディレクトリの (parent) リビジョンであった rev 2 に対するブランチである点に注意してください。コミットにより、rev 4 がその時点での作業領域ディレクトリの parent リビジョンになります。

3. リビジョン、チェンジセット、head および tip

Mercurial は、複数のファイルに対する関連する変更を、単一不可分なチェンジセットに分類し、これらがプロジェクト全体におけるリビジョンとなります。これらはそれぞれ一連のリビジョン番号を持ちます。Mercurial は分散並行開発を許容しているので、ユーザー間でこれらの番号が食い違う可能性があります。そのため、Mercurial は各リビジョンにグローバルなチェンジセット IDを割り当てます。チェンジセット ID は 40 桁の 16 進数ですが、"e38487" のように、紛らわしさのない長さまで省略可能です。

履歴中のブランチの分岐やマージは、任意の時点で発生し得ます。マージされない個々のブランチは、履歴中に新規のheadを形成します。 この例では rev 5 および rev 6 が head です。Mercurial は、最もリビジョン番号の大きい head として、rev 6 をリポジトリの tip とみなします。 リビジョン 4 は マージ チェンジセット で、 parent チェンジセットが 2 つ あります。(リビジョン 2 と 3)

4. 複製、変更、マージ pull および更新

Alice に以下のようなリポジトリがあるとしましょう:

Bob がこのリポジトリを複製 (clone)すると、 Alice の store の完全なコピーを得ることが出来、作業コピーには最も新しいリビジョン d がそのままチェックアウトされます:

Bob は Alice と無関係に作業を進められるようになり、 e と f の変更をコミットしました:

一方 Alice は独自に g という変更を加えました。 これで Alice のリポジトリ store は Bob から枝分かれし、 ブランチ ができたことになります:

ここで Bob は Alice のリポジトリを pull し、同期を取ります。 Alice の変更点が全て Bob のリポジトリ store へコピーされます。(ここでは、 g の変更だけです。) Bob の作業ディレクトリは pull によって変更 されない ことに注意しましょう:

Alice の g が Bob のリポジトリにおける最新の head なので、この時点で g が tip となります。

ここで Bob が マージ すると、 Bob が作業していた最新の変更 (f) とリポジトリの tip が結合されます。 作業コピーには 2 つの parent リビジョン (f と g) ができました:

作業コピーのマージ結果を調べて、マージが完璧だと確認したら、Bob は結果をコミットし、 マージ チェンジセット h が Bob の store にできます:

ここで Alice が Bob から pull したら、 Bob の e, f, h の変更が Alice の store へ取り込まれます:

Alice の作業ディレクトリは pull によって変化しないことに注意しましょう。 作業ディレクトリをマージチェンジセット h へ同期するには、 更新 (update) する必要があります。 これで、作業ディレクトリの parent チェンジセットが h へ変わり、リビジョン h の内容へ作業ディレクトリのファイルが更新されます。

さぁ、再び Alice と Bob はすっかり同期が取れました。

5. 分散型システム

Mercurial は完全な非集中型のシステムですので、中央リポジトリといった内部概念がありません。そのため、変更を共有するための伝播経路を、ユーザが自由に定めることができます。 (CommunicatingChanges 参照):

集中バージョン管理システムでは実験が面倒なことになりがちですが、 Mercurial のような DVCS では、 clone して試してみるだけです。 結果が気に入れば逆に pull し直し、そうでなければ clone したリポジトリをきれいさっぱり忘れて別のことを試せばよいのです。

6. Mercurial ができること

SVN や CVS ユーザーは、関連するプロジェクトをひとつのリポジトリへまとめがちです。 これは Mercurial には全くそぐわないため、別の方法でやってみなければなりません。 具体的に言うと、リポジトリのディレクトリひとつだけをチェックアウトできないということです。

どうしても複数のプロジェクトをメタリポジトリのような形で提供する必要があるなら、 サブリポジトリ 機能を使ってみると良いでしょう。 Mercurial 1.3 より古い場合は、 ForestExtension を検討してください。

Mercurial 利用に関する実践的な入門は、 チュートリアル を参照してください。

Brazilian Portuguese, Czech, Deutsch, English, Français, Italiano, Russian, Spanish, Thai, 中文, 한국어