Mercurial と Trac のメモ

Mercurial（公式サイト）

Mercurial: a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.

大きな特徴

Mercurial is Fast, Scalable, Robust, Easy to Use, Easy to Adopt, and Free

速い、スケールできる、堅牢（←しっかりしてる）、使いやすい、導入しやすい、フリー（オープンソースかつ無料）。


英語チュートリアル／日本語チュートリアル

This tutorial is an introduction to using Mercurial. We don't assume any particular background in using SCM software. This tutorial is also available in French, following FrenchTutorial, in Spanish, following SpanishTutorial, in Japanese, following JapaneseTutorial, and Chinese, following ChineseTutorial

このチュートリアルは Mercurial の使い方を紹介します。SCM ソフトウェアを使うにあたっての特定の予備知識は必要ありません。このチュートリアルのフランス語版は FrenchTutorialから、スペイン語版は SpanishTutorial から入手できます。

Windows、BSD/OS、Linuxでの使用体験＠かえるの寝言

python でかかれた分散SCMらしい。gnu-arch MLで比較に上がっていたので知る。

早速widnows で使ってみようと、展開してpython setup.py install する。あっさり成功。mpatch.c を見る限りMSVCを考慮してあるから当たり前かも。 windows なのでscript としては動かないから、 alias hg=python c:python23scriptshg としておく。 hg clone http://selenic.com/hg/ と実行してリポジトリをclone してみる。なんの問題無く動く。proxy もちゃんと効いてる。こんなに簡単で良いの？ この間10分もかかってない。素晴らしい。

同じことをBSD/OSやLinux でやってみる。あっさり動く。5分程度。

http 経由以外にもssh でもいける。コマンドも15で割と単純。

tarball にはcgi も入ってる。 hgweb.cgi を編集してリポジトリを指すように変更して実行すると、 web で状態が見られる。過去のchangeset からその内容をリストしてくれる。またこれはhttp 経由での公開の口でもあるようで。 viewとsource が一緒になっていると。上記の http://selenic.com/hg/ がその例。CGIが可能な環境であれば、これも、動かすのはとても簡単でした。簡潔なのだけど、機能してる素敵さ。

ちなみにcomparison.txt というのが含まれていて、 git とBK との比較は載っているのだけど、tla などとの違いは書いてないので、そういうのはわからんし、この手の分散SCMの勢力図はどうなってるのかを知らんのだけど、ここまでシンプルだと、もうそれだけで興味が湧いてしまい使ってみたくなるというもの。
## svn なんざbuild するのに要する時間たるや...

さて、python ベースということもあり、Trac に取り込むていうのが思い浮かぶわけですが、最近分離されたscm backend の部分は全く理解していないので、そこから始めないと。

reddit.com でのお気に入りのソースコード管理システムの議論 --- Ask Reddit: What's Your Favorite Source Control Program, and Why?

vog
What about simply using Darcs or Mercurial? It's not just the "distributed feature", it's another way of thinking about your project development.

...

Darcs is very nice and has a pleasant command line interface. It's very interactive, more than e.g. Subversion, Mercurial, GIT, etc..

However, for bigger projects I prefer Mercurial because of its simplicity and better performance.

Decentral version control systems (Darcs, Mercurial, ...) have also a big advantage when used for stand-alone home projects. Having a central Subversion repository at home is a hassle, also Subversion's hard distinction between "repository" and "working directory".

I'm still using Subversion for really centralistic projects, or when I need compatibility and good clients for win32. But my home projects I switched to Darcs or Mercurial, because they are * easier to set up * easier to use * and more powerful.

...

There's little information about that. I think, most projects switch from CVS to Subversion and stick with it.

Newbies will also use Subversion, because it's mainstream, but some interesting dicussion in the BeLUG (LUG of Berlin) showed that distributed version control systems are more natural and usually easier to understand even for beginners.

So a newbie has (as always) the choice between "very good stuff" and "mainstream moderate good stuff".

The Linux kernel hackers use GIT.

However, Mercurial has a more active community than GIT, so in the future it may become the first choice of new projects. Mercurial is written in Python, so it has a big acceptance even for "hip-geeks".

Bazaar and Darcs are less common. If Darcs just had a bigger community it may become the best one, IMHO. For small projects it's perfect. However, Darcs has less acceptance among "hip-geeks" because it is written in Haskell. This is unfair, but sadly a self-fulfilling prophecy.

gecko
"It depends."

Subversion is great when you need a centralized, free-as-in-speech source control system, and certainly it's vastly superior to CVS, but its' also far from perfect.

* You can't work offline (at least, not without hacks like svk)
* There is no way to see the merge history of a file, which makes branches useless compared to nearly any commercial version control system (say, Perforce or ClearCase, for example)
* Getting secure remote repositories going usually has painful complications (either getting Subversion tied into Apache, or sorting out masking issues over SSH)

We use a large Subversion repository at my company, and my major complaint in that context is merely the branching, but for my own projects, where I neither have a central server nor want to be dependent on one, I prefer the distributed version control systems. In those systems, each person working on a project has a full copy of the revision tree. Instead of checking in to a centralized location, you pull changes from other people working on the project. The major tools in this arena are Darcs and Git, with several lesser-known tools, such as Mercurial and Bazaar-NG, pulling up the rear.

Because distributed version tracking software has to deal with far more merges, these tools (usually) have vastly superior merge tracking than Subversion. My favorite of them is darcs, which actually lets you intelligently permute file changes, cherry-picking which changes you want, and which has a wonderfully easy command set. The problem with darcs is that it does not scale well. It would be utterly inappropriate for the source tree we use at work. BitKeeper, which provides darcs-like merging but scales far better, is a great choice if you don't mind spending money, but for that reason is not acceptable for most hobbyist projects.

So, to answer your original question succinctly: Subversion for large projects, darcs for smaller ones.


trickos
I stopped using it and switched to Mercurial for my spare-time projects after I hit the famous degenerated merge problem:

""" Nobody has proved that the performance of conflict-conflict merge corner cases can be improved from O(exp n) """

When you get that, you are just stuck. And it really happens. The codebase was just a bunch of python files, I never got what was causing the merge to stall. That's too bad because Darcs has very interesting stuff in it but I no longer trust it.

In comparison, I found Mercurial to be much faster for everything, to have a very active community. And it is in python.

pjdelport
Mercurial, because of its simplicity and elegance. (That it's also fast, efficient, and scalable (to big projects/workloads) certainly doesn't hurt.)

僕がよく理解できないもの、情報のソースがはっきりしないもの、一見矛盾するものも含めて、上の内容のポイントを誰が発言したものかすら無視して適当に並べる（表現がほとんど同じの重複した意見はとばす）：

• バージョン管理システムにはおおまかに２種類ある。中央集権的なものと、分散的なもの


• Darcs や Mercurial は分散的なもの。CVS （←もう古い）や Subversion は中央集権的なもの


• Darcs のコマンドラインはほかのより対話的でよい


• Mercurial はシンプルでパフォーマンスは Darcs よりいい


• Darcs や Mercurial の分散的なアプローチはネットワークにつながってないスタンドアロンのマシンにも向いている


• Subversion の「レポジトリ」と「作業ディレクトリ」の区別がつきにくい


• 中央集権的なアプローチでは Subversion がまだ力を持っている。互換性がよくて Win32 向けのいいクライアントがある


• Darcs や Mercurial は Subversion よりセットアップが簡単で使いやすくて、もっとパワフル


• 多くのプロジェクトは CVS から Subversion に移行して、そのままそれを使いつづけている


• 初心者の多くも Subversion を使う。みんな使ってるから


• BeLUG (LUG of Berlin) の議論で、分散型のバージョン・コントロール・システムのほうが自然で初心者にとっても理解しやすいと示された


• だから初心者の選択は「とってもいいもの」（←Darcs や Mercurial）と「みんなが使っているそれなりにいいもの」（←Subversion）


• Linux カーネルのハッカーは GIT を使っている


• Mercurial のコミュニティは GIT のそれよりもアクティブだから、将来的には新しいプロジェクトのはじめの選択になるかも


• Mercurial は Python で書かれているから、"hip-geeks" にもウケがいい


• Bazaar と Darcs は（Mercurial より）マイナー。Darcs はもっとコミュニティが大きければベストなものになるかも


• Darcs は小さなプロジェクトには完璧


• Darcs は Haskell で書かれていて "hip-geeks" へのウケはいまいち


• Subversion は中央集権的なものではすばらしい。フリーだし、CVS よりだいぶいい


• Subversion のダメなとこ： svk とか使わないとオフラインでは使えない。ファイルの履歴をマージする方法がない（商用のPerforce や ClearCase なんかにはこれができる）。安全なリモート・レポジトリの設定が複雑（Apache や SSH と一緒につかう時とか）


• 分散システムではそれぞれのひとがリビジョン・ツリーのコピーを持つことができる。中央にチェックインせずに、プロジェクトにかかっている人から pull できる


• この分散システムのメジャーなツールは Darcs や Git。より知られていないツールに Mercurial や Bazaar-NG がある


• 分散システムはよりたくさんのマージを処理するから、多くの場合分散システムのほうが Subversion より優れたマージ・トラッキングの機能をもっている


• Darcs がお気に入り。変更の順序を賢く変えたり、ほしい変更を cherry pick できたり、すばらしく簡単なコマンドセットをもっている


• Darcs の問題はうまくスケールしないこと。仕事で使うソースツリーには向かない。


• 商用の BitKeeper は Darcs のようなアプローチでちゃんとスケールするが、趣味人には向かないだろう


• 結論：大きなプロジェクトには Subversion。小さなプロジェクトには Darcs。


• Darcs に問題があって Mercurial に移行したことがある。この問題にはお手上げ状態だった。Mercurial は Darcs より速くてコミュニティが活発で Python で書かれているのがいい


• Mercurial はシンプルでエレガント。速くて効率よくてスケールできるからやって損しないだろう

OpenSolaris の Mercurial に関する Wiki ページ

In order for the OpenSolaris community to make progress, and in order to support new and current projects and consolidations that are not tied to TeamWare, two parallel efforts related to SCM support are being pursued. A Centralized SCM facility and a Distributed SCM (DSCM) solution will be supported. Subversion was chosen for the centralized solution and Mercurial for the distributed one.

OpenSolaris プロジェクトでは集中型のシステムに Subversion、分散型に Mercurial が選ばれた。


Trac（公式ページ）

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission; to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.

Trac の Mercurial プラグイン（画像つき）のページ

There is an experimental plugin for Trac 0.10 which enables Mercurial to be used instead of Subversion as the VersioningSystemBackend for Trac.

The plugin being experimental, expect some rough edges and a somewhat unstable set of features/documentation...