コグノスケ

ぱわぽーいんと

先日注文したMicrosoft PowerPoint 2007が届いたので早速インスコ。

噂の使いづらさに絶句するかと思いましたが、リボンインタフェースでしたっけ、そんな言われているほど悪くないと思います。

ただ配置をアグレッシブに変えすぎたせいで、覚え直すのがかなり面倒です。巷で使いづらいと文句を言っている人の大半は、恐らく今の私と同じ心境なのでしょう。

Officeの箱は正直邪魔くせーです。しかも妙に立派なので捨てるも忍びないのです。CDと小冊子しか入ってないくせになんでこんな分厚くするんだか。同時に注文したOffice Personalが届いたら一緒に並べて写真でも撮って載せますか。

さいのみやこ、彩都（さいと）へ

車でガーデンモール彩都（大阪府茨木市）へ行きました。大阪モノレール彩都西駅のすぐそばですが、電車で行こうとすると2回も乗り換えなければなりません。しかもモノレールの料金がアホみたいに高い（往復で1,000円超）から、電車でなんか行けません。馬鹿馬鹿しい。

さいのみやこ、と書いて彩都（さいと）とは、さいたま市顔負けの恥ずかしさですね。

モスバーガーでご飯を食べた後、ガーデンモールを一通り見ました。つくばのララガーデン的なショッピングモールを想像していたのですが、全然違った。店は平和堂（スーパーマーケット）、本屋と、100均の店が離れて建っているだけです。うーん。率直な感想は「中途半端」だな…。

新興住宅地らしくて、周りの道路や建物は綺麗です。いかんせん人が居ないね。

体力の限界がきたらしい

最近の規則正しい生活にはやはり無理があったようです。ついに限界が来ていつもの生活に戻ってしまいました。

昼まで寝てSenaさんの「昼飯くわねー？」メールで起きる生活。ああ…これだよ、これ。やっぱり休日はこうでなければ。

飲み会

同期の人と飲み会しました。一応合コンという触れ込みだったのですが、知り合いは合コンとは言わんよなあ…。

四条駅近くのレストランIRO（京都府京都市下京区）というところです。

混んでいたらしく料理が全然出てこなかったり、かと思えばすげー早く出てきたりして店員さんがパニクってた模様です。

京都の飲食店でバイトなんて絶対やりたくないな…と思った。

奇跡の一週間

ここ一週間、目覚ましより早く目が覚め、一切寝坊もせず、電車にも余裕で間に合う、そんな朝が続いています。

こんなことは去年一回もありませんでした。一体どうなってるんだろう。まさかどこか体を悪くしたのではなかろうか…？

推奨

友人と話していたら、水曜日は定時退社推奨日だよね、って話になった。そういえばそんな日だったかな。誰も実践していない気がするんだけどな…。

Mercurial Mini HOWTO

目次: Linux

分散リポジトリ型のバージョン管理システム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(・∀・)イイ！

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

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

野菜だらけ

Sena氏と買い出しに行って、野菜生活100を補充しました。元々あったやつと合わせて、40本くらいになった模様。意外と消費期限は長い（3ヶ月くらい）ので問題なし。

どかーんと冷蔵庫の上に積んでおいたら、同室の隣人が「なんか増えてません…？」って呆れてたけど、気のせい気のせいｗ

晩はびっくりドンキーで食ったんですが、40周年記念メニューを一押ししていました。まあいつもとおなじハンバーグですけど…。

イチゴミルクとマンゴージュースはおいしかったなあ。どちらも果肉成分がたっぷり入ってるのは良いんだけど、ストローで飲むと詰まって出てきませんよー！二人ともスムーズに飲めなさすぎて、途中からなんだか笑えてきたよ。

さらに延滞

先日、同室の隣人からDVD返しておいてくださいな、と頼まれました。延滞してるから後で払います、よろしく〜と、彼は再び岡山へ旅立って行きました。いつも大変そうだなあ…。

で、そのDVDは本来昨日返すべきだったのですが、中の映画（ボーン・アルティメイタム）が気になって見てたら閉店時間を過ぎてしまった。余計に延滞してしまったぞ。

今日返したら4日延滞と言われ1,200円も取られた。延滞料金って高いのな…。

金曜は寿司の日

同期のSenaさんと寿司を食いに行きました。というか今更書かなくても毎週行ってますけど…。Senaさんは、寿司ばっか食ってる私に、飽きずによく付き合ってくれてありがたいです。

富田駅の近くにある権太呂寿司です。回らない寿司屋だけど2貫で126円（税込）と、値段は回転寿司並のリーズナブルさが良いのです。

最近はビントロばかり食ってます。あっさりなのかこってりなのか良くわからないこの感じが、何とも言えないぜ。