いま分散バージョン管理が熱い(か?)
http://changelog.complete.org/posts/596-guid.htmlコレと
http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.htmlこれをナナメ読み。あと Gauche部屋@Lingr で教えてもらったけど
http://slashdot.jp/~YamaKenZ/journal/392632とか。
うーんそんなに Mercurial がいいのか、うーん。よくわからんけど試してないからなあ。使ってみてからモノを言え感は、確かにあるのだよね。
しかし誰もかれもまっさきに挙げている「速い」っていうのも、よくわかんないんだよな。darcsは遅いと言われるけれど、実用的なレベルで遅いと思ったことがないので、速いことにも利点を見出せないのですよ。そんなことより使い方というかコンセプト(=心理的な楽さ)の方が重要でしょ。
わたしは darcs の完全にパッチベースなところが気に入っている。ロジックに一貫性があるし、シンプルでわかりやすい。一見とっつきにくいように見える人もいるかもしれないけれど、それはまやかしで、習得はとても楽だ。なので履歴管理の方が優れているとするヤマケンさんの意見は、正直よくわからない。 メーリングリストであれこれ相談するときの話だろうけれど、うーん。そんなに問題になるとも思えないんだけど。ただし両方をある程度使っていないとわからないだろうから、その点は保留する。
というわけで、別にどっちでもいいけれど(あるいはmonotoneでもgitでもbazaarでもいいんだけど)そろそろ真面目に分散バージョン管理などいかがかと思っていますがどうですか。今年の Japan Linux Conference ではチュートリアルが応募できるようなので darcs のチュートリアルなんかどうかな、と思っててまだ何も書いていない俺です。
さて、こんなのを書いてるうちに Mercurial のインストールが完了したので、Mercurialの利用を読みながら少し勉強してみるかね。
追記
チュートリアルが和訳してあったので読んだ。ガイジンらしいヘンなテンションを除くと darcs でごくふつうにできていることなので特に何が優れているとかいうことは特に感じなかった(どうでもいいけど、エクスクラメーションマークを多用する文章は胡散くさくて嫌いだ。それをそのまま訳すのも、馬鹿みたいで嫌だ)。
実際にやってみたらHGENCODING の設定をしないとそもそも動作しなかったり(最近の Mercurial を Mac で動かそうとするとそうなるらしい)、ユーザ名(メールアドレス)がヘンなことになったりしたけれど(これも設定すればいいのだろう)、まあふつう。
っていうか Mercurial って pull はあるけど push はないのか?……いや、あった。びびった。ふーむ。渡された変更は update するまでソースツリーに影響を及ぼさないのか。何かメリットがあるのだろう?
なるほど。ヤマケンさんの言う「連番」というのは、レポジトリ単位でしか生きないもののことなのか。「あいだに変更が挟まったらどうするんだろう?」って思ってたけど、そうはならずに単調増加していくのね。でもそのかわり、コミットの順番なんかによってはレポジトリによって番号はすぐ変わる。けっきょく議論する場合にはチェンジセットのハッシュ値を使うことになりそうな気がするんだが……。
現在の変更がすべていちどにコミットされてしまうのは、オレみたいな横着者には嬉しくないな。2つの内容の変更をしても、 darcs なら「今回のコミットに含めるのはどの変更ですか?」ってなる。もちろんその場合でも、隣接領域を修正すると意味的に2つの変更のものが「ひとつの変更」と解釈されることもあって、必ず上手くいくわけじゃないんだけれど、あれはあると嬉しいんだけどなー。 darcs みたいにパッチベースじゃないと無理かなー。
というわけで、ほんの少しだけ使ってみた感想だと「やっぱり darcs の方がいいよ」と(オレは)なってしまうのだけれど、それはオレが darcs 信者だからなんだろうか。基本的には大差ないような気はするが、細かいところの違いでそれでも darcs の方が気が効いているように、まだ思っている。それに対する Mercurial の利点は、まだ速い「らしい」というところしかわかっていない(確かに簡単なチュートリアルはさくさく動くけれど、たぶん速さが効いてくるのはデカいプロジェクトの場合だ)。
Darcsは、コンフリクトが複雑になるとハングする場合があるとか聞きますけど (出典失念)
わたしがむかし書いた記憶があるんですが(探すのが面倒なので略)、「同じことをする違うパッチ」を充てようとするとおかしくなることがありますね。たとえば、 include っていうディレクトリを作ってそこにヘッダファイルをつっこむような変更をふたりの人がやっていて、そのパッチを両方とも取り込もうとすると、固まります。
そもそもそんなケースはまずありえないと思いますが、まったく別のプロジェクトをマージする場合、 darcs では起こりうると言えなくもない。
そういうものではない、ごくふつうのコンフリクトではハングしたことないし、常識的に考えてそんな大変なことにはならないんじゃないかな、と思います。パッチの依存関係の処理とかの方が、ややこしいことになる可能性は高いです。
マージアルゴリズムで比較して考えるとよいかもしれません。
http://revctrl.org/CategoryMergeAlgorithm
個人的にdarcsの気に入らないところはrepositoryがconflictするところです。
monotoneも同じ理由で好きになれませんでした。
ありがとうございます。挙げられたページは量が多いので、この週末に少し読んでみたいと思います。
> 個人的にdarcsの気に入らないところはrepositoryがconflictするところです。
なるほど、それはわかります。