コグノスケ

Mercurial Mini HOWTO

分散リポジトリ型のバージョン管理システムMercurialの簡単な説明と操作法を書きます。

そもそもバージョン管理システムって何さ？という話はしません。全て説明するのはここでは無理です。世の中には良い書籍がいっぱいありますんでそれを読んでね。

はじめに - Subversion以降のリビジョン番号について

CVSとSubversionの差は色々あるけれど、リビジョンの考え方が激変しました。これは大事だと思うから説明します。

CVSではリポジトリに対する変更をファイル単位でコミットし、リビジョン番号もファイルごとに振ります。

一方Subversionはリポジトリ全体に対してリビジョン番号を振ります。ファイル一つ変更するだけでリポジトリ全体のリビジョン番号が上がるのです。

Subversion等のリビジョン番号

図中の丸印が「ある時点のリポジトリ」を表しています。リビジョンを何かに例えるなら写真の番号でしょうか。コミットは「リポジトリ全体を写真に撮って、番号（＝リビジョン）を付けること」に相当します。

リポジトリには今までの全写真と番号が保管されていまして、好きな番号で写真を引っ張り出せます。二つの写真の間違い探し（diff）もできて、被写体（リポジトリ）がどれだけ変わったか（ファイルの追加、変更などの変化）が簡単に追跡できます。

便利な例を一つ。一週間前から今までの全変更点を追跡したくなったとします。

CVSですとリビジョン番号はファイル毎に付くので、一週間でファイルAはリビジョン100進んで、ファイルBはリビジョン1も進んでないなんてことが起こります。一週間前の状態に戻そうとすると、ファイル毎にどのリビジョンを見るべきかチマチマ調べなければなりません。

Subversionならば一週間前のリビジョン番号を調べ、そのリビジョンにリポジトリを巻き戻すだけ（update -r revision_number）です。すると全ファイルが当時の状態に戻ります。タイムマシンのようですね。

Mercurialもリポジトリ全体にリビジョン番号を振る方法を採ります。他のSCMもたぶんそうでしょう。

集中型リポジトリとの違い

区別のためにMercurialの管理方法を分散リポジトリ形式、Subversionの管理方法を集中リポジトリ形式と呼びます。正式名称は知らないです。

集中リポジトリ形式ではリポジトリは一つだけです。利用者はリポジトリの一部をコピー（checkout）していじって、変更を反映（commit）したり、他者が行った変更を取り入れ（update）て使います。

Subversionはさらにローカルにリポジトリのキャッシュを持っていて、diffやstatusコマンド実行の際、リポジトリとの通信が不要です。この機能はリポジトリにアクセスできない状態（オフライン）でも使えるのでとても便利です。

Subversionのリポジトリ

Mercurialは分散リポジトリ形式の名の通り、リポジトリがいくつもあります。大きく3つの領域に分類できます。

他人のリポジトリ

他の人が変更しコミットしているリポジトリです。他人の〜と言っても誰が作ったかではなくて、ローカルリポジトリ以外のリポジトリは全て他人です。
どこにあっても良いので、オフラインではアクセスできないかも知れません。

ローカルリポジトリ

自分がコミットする対象としているリポジトリです。HDDなどに置きます。オフラインでもアクセスできます。

作業コピー

実際に作業してファイルを変更する場所です。変更後はローカルリポジトリにコミットします。

以下の図でイメージを掴んでいただけるかと思います。

Mercurialのリポジトリ

実はmercurialの場合、ローカルリポジトリと作業コピーが同一の場所にあります。実用上は便利なんですが。説明する側から見るとやりづらいっすね。

オフラインでリポジトリにcommitできること、これこそが分散リポジトリ型の最大の利点です。
絵から分かる通りupdateもできます。オフライン状態でローカルリポジトリを変更できるのは自分だけだから意味無い？なんてこと言うんですか…。updateの節で詳しく説明しますが、バージョン管理のうまみはupdateで巻き戻せる点に有ります。

commit

作業コピーに対する変更点をローカルのリポジトリに反映させます。

push

pushできるのはリポジトリ同士なのでcommitしてからpushして下さい。そうでないと何も反映されません。

誰かが先にpushしていると、

$ hg push
pushing to /home/user/test-a
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

と警告されます。headとは最新状態のことです。ある地点を基点にブランチで枝分かれしていき、枝の末端が最新版となります。末端なのにheadというのも何だか変（※）ですけど、そういう用語なので仕方ないですね。

謎のキーワードheadがわかれば警告文の意味がわかります。このままpushすると最新の状態（head）が2つできるじゃない！何とかしなさいよ！！と言っているわけです。

図示すると以下のような感じです。

Mergeが必要な場合

この状態を解消するためには「誰かの変更」を取り入れる作業（pullしてmerge）が必要です。詳しくはpull, mergeの節を見て下さい。merge後はcommitしないと作業が進められなくなりますよっと。

警告文曰く、ブランチを作りたいならpush -fで作れるそうです。

（※）個人的にはleafの方がわかりやすいと思いますが、歴史的な経緯でしょうか？

pull

別のリポジトリにある変更点をローカルリポジトリに反映させます。さらに作業コピーに変更を反映させたければupdateをする必要があります。updateについては次節をご覧下さい。

update

作業コピーにローカルリポジトリの内容を反映させます。

他のリポジトリからpullした後は、通常はupdateをします。もし誰かが既に更新していた場合は「衝突」状態になります。その時は次節で説明するmergeを行って解決します。

別の使い方は「巻き戻し」です。○○という変更を入れる前に戻したい、1日前に戻したい、なんてことが簡単にできます。

merge(またはupdate -m)

他のリポジトリからpullした変更点をupdateしようとすると

abort: crosses branches (use 'hg merge' or 'hg update -C')

と、怒られることがあります。あなたがpullしたリポジトリに、誰かが先にpushしたことを表しています。

（ブランチの絵を入れます）

解消するためにmergeを行います。マージ用のプログラムが無い状態では、衝突したファイル名に .origが付加されてバックアップされます。

$ hg status
M a.txt
$ ls -1
a.txt
a.txt.orig

$ cat a.txt
a
b
c

$ cat a.txt
a
user a
c

$ cat a.txt
a
user b
c

同じ行を変更しているので機械的にマージが出来ません。するとマージプログラムは以下のようにlocal（自分の変更部分）と、other（他の人の変更部分）を示して、どちらか選んでよ、もしくは良い感じに修正してよ。

衝突したファイルはどうなるかというと、

$ cat a.txt
a
<<<<<<< local
user a
=======
user b
>>>>>>> other
c

修正後にcommitをお忘れ無く。

rollback(またはundo)

親リポジトリからpullした、あるいはcommitしたは良いけど、やっぱりやめたいときはrollback（またはundo） ができます。

ローカルのリポジトリを巻き戻します。最後にpull, またはcommitした部分まで戻りますが、二回以上は戻りません。

メモ置き場

後で調べて書きたいこと。

• ブランチの消し方？
• リポジトリを省略したときに操作の対象になるリポジトリの調べ方？
• 誰でも書きつぶせるのは危ない、アクセスコントロール、パーミッションなど？

とーどー(TODO)

• ビルド、make PREFIX=, PYTHON= あとはPYTHONPATHの設定あたり？
• statusとlog（tipまたはhistory）の説明も
• cloneとinitの説明も
• リポジトリ作成、clone -> コミット、プル、プッシュ、マージの一通りの流れ、実例交えて

使った感想

オフラインコミットは便利d(・∀・)イイ！

昔はそう思ってました、今はリポジトリが散らばりすぎて何だかわからなくなった俺ガイル…なんてことにならないように、ある程度の規模を扱う予定ならば運用ルールを敷きましょう。

本格的に使ってないので予想の域を出ませんが、リポジトリが大量にできるうえに全リポジトリが平等なので、集中リポジトリ型よりめちゃくちゃになりやすい気がします。