プロダクト関係が鬼門というのは明白として、テーマをまた書き直すのがめんどうくさいなと思いつつ、でもそうすればMercurialだってもっと手になじんでくるのではないかという希望を持ちながら、とりあえずデータだけ移しちゃえということで、いざPlone3へ。

プロダクトをアップグレードするときは、一度アンインストールしてからもう一度インストールし直すのが吉なのかもしれない。

先日、東海でPythonを語りたいという小田切さんの仕切りでPython東海キックオフの集まりが開催されました。前日までは参加者予定者が5，6人という、やや寂しい状況でしたが、直前になってドドドっと参加者が増加し、最終的には11名というそこそこのボリュームとなりました。内訳は、会場を提供していただいたVishの方々が3名、PythonWS東海参加組が3名（私含む）、Della.jsの方々が5名となりました（たぶん）。

当初は少人数でだらだらしゃべりながらという流れを想定していたようですが、予想外の二桁参加者のため、急遽発表形式での進行となりました。発表は船井さんによるMercurialの説明および小田切さんによるGAE（Google App Engine）の説明の2本立てとなりました。私はGAEの発表の途中で用事が入ったため、その後の流れは不明ですが、両方ともあまり触れたことのないものだったので興味深く聞くことができました（いつも受け身で申し訳ない）。

以下、船井さんのMercurialの説明を元に、メモして私の言葉に書き直したものをまとめておきたいと思います。

Mercurialとは

Mercurialとはソースコードを管理するソフトウェアです。ソースコード管理というと小難しいとかプログラマーにしか関係なさそうとか考えてしまいそうですが、HTMLやCSSなどWebデザイナー・コーダーの作業範囲にあるものにも十分適用できるものです。たとえばCSSハックなどは時代（ブラウザ）と共に変化していくものですから、後から書き方を変えたり、より簡潔でわかりやすい表現に変えたり、といったことがあると思いますが、そういった場合にはどこをどのように変えたのかなど後から確認できた方がよいでしょう。

ただ、ソースコードを管理するためのソフトウェアはもちろん他のものもありますので、「なぜそれを選ぶのか」といったことを考えておく必要があるでしょう。

Mercurialの特徴

現在ソースコードを管理するためのソフトウェアとして多くのプロジェクトで利用されているのは「Subversion」ではないでしょうか。古くから使われていたCVSの弱点を克服し、また移行も容易なSubversionはあっという間に世間に広がっています。私もPloneの開発中プロダクトなどを利用する際にはよく使っていますのでなじみが深いです（ダウンロードするだけですが…）。

このSubversionは、プロジェクトを管理するための作業場をサーバに用意し、そこに変更をアップロードしたり、最新版をダウンロードしたりする「集中管理型」の体制をとりますが、Mercurialはサーバ不要、ローカルの作業ディレクトリでソースコードの管理をする「分散型」アプローチをとっています。

この「分散型であること」がMercurialの一番大きな特徴となっています。ただし、この分散型アプローチを採用しているソースコード管理ソフトウェアとしては、高名なリーナス・トーバルズが開発した「git」があり、必ずしもMercurialを積極的に選ぶ理由にはなり得ないという現実はあります。

その他の特徴としてはまず、ほとんどがPythonで書かれているということがあります。これはPythonistaとしては使ってみようというモチベーションが上がる部分だと思います。実際、船井さんがMercurialを使うようになった理由はこの点であるようです。もう一つの特徴はインストールや設定が非常に簡単であること。特に設定に関してはインストール後ほとんど何もすることなく利用を始めることができますので、個人でお手軽にソースコード管理を始めようと思ったらすぐ始めることができます。そんなに本格的に管理することもないし、環境作りにあんまり時間をかけたくないなぁと思う人にはぴったりの選択だと思います。

その他にも様々な特徴がありますが、とにかくPython好きな人が簡単にソースコード管理を始める場合にステキになれそうな選択といえそうです。

もちろん本格的にプロジェクトで利用することも可能です。実際にMercurialをソースコード管理ソフトウェアとして利用しているプロジェクトとしては

• Mozilla
• OpenSolaris
• Pylons
• NetBeans

といった有名なソフトウェアプロジェクトがあります。

Mercurialを使う上でのあれこれ

細かい使い方はググればすぐ出てきますのでそちらにお任せするとして、船井さんの発表の中で気になった点などを簡単にまとめておきます。

とにかく始めるのが簡単！

hg initはソースコード管理を始めるためのコマンドです。このコマンドにより管理のための「.hg」というフォルダ（および様々なファイル群）が生成されますが、これらの管理のためのファイルが作業ディレクトリの最上階層にのみできますので、管理をやめるのも簡単です。使い始めるのが非常に楽ちんですね。

コミットするときには必ずコメントを

変更をコミットする際には「hg commit -m 'comment'」というような書式で行いますが、どのような変更を行ったのかコメントを必ず残すようにしましょう。空コメントは拒否されるように作られているため、「-m 'comment'」をつけないとエディタが立ち上がりますし、それでもコメントを書かずに保存しようとすると、エラーでコミットできません。ちなみにコメントに日本語は（完全ではありませんが）通ります。

rollbackは最後の手段

やり直しのコマンドとして「hg rollback」というものが用意されています。これを行うことで直近のコミットに状態を戻すことが可能になりますが、「たまに、ごくまれに」壊れてしまうことがあるようです。船井さんもこれまでに2度ほどrollbackでおしゃかにしてしまったことがあるそうです。

複数人で利用する場合には運用方法を考えておく

分散アプローチを採用しているMercurialでは、複数人で作業している間にいわゆるブランチができることが普通に起こります。こういったブランチができた場合にはコンフリクトを管理したりマージしたりする必要が出てくるのですが、こういった状況においてどのようにアップデートするのかなどを考えておかないとわけがわからなくなってしまいます。どのように運用するのかをあらかじめ決めておけば、こういった混乱を避けることができます。

Mercurialをより使いやすく、より楽しく

Mercurialは基本的にコマンドにより操作しますが、GUIフロントエンドもあります。SubversionのGUIフロントエンドとして有名なTortoiseSVNと同じようなTortoiseHG、あるいはEclipse用のプラグインであるMercurial Eclipseなどがあります。

また様々なプロジェクトを公開しているリポジトリホスティングサービスとしてfreehgやbitbucketといった場所があります。

個人的な使用感

とにかく簡単に始められるという実感が大きいです。たとえばPloneのスキンを作成する際に書くCSSは非常に大きいのできちんと管理したいなぁと思っていたのですが、Mercurialをインストール、hg initするだけで始められるのでお手軽感が非常に高かったです。また一人で使う分にはコンフリクトやマージを意識することがありませんので、さらに投資資源が少なくてすみます。

ばりばりのプログラミングで使うのもよいですが、Webプロダクションの管理ツールとして使うのも便利そうです（Mercurial＋Tracとか？）。

こういった有用なソフトウェアを紹介してくれた船井さん、および今回の集まりを企画してくれた小田切さんに感謝の意を表して筆を置きます。

Webデザイナの聖地「A List Apart」にJeffさんの記事が掲載されました。Djangoに代表される、いわゆる「フレームワーク」とはあまり関係ありませんが、フレームワークという概念を再構成する意味でとてもおもしろかったです。

私の場合、頭の中で意味の強くなった概念は思考の流れをスムーズに、直線的にしてくれるのですが、その代償として論理が単純化されすぎて発展的な思考ができない事態に陥ります。そういう状況の中で内省できるだけの余裕があればいいのですが、実際にはどん詰まりの八方ふさがりになった気分になってしまうことが多いでしょう。

思考のコストと柔軟性、このバランスがうまくとれるようになりたいなと思ったのでした。