「分散型バージョン管理システムはどれが良い?」記事へのコメント

今はMercurialをメインで使用中

[ioctl (606)]

バージョン管理システムは、CVS, Subversion, Mercurialと使ってきて、今は新規開発ネタは主にMercurialを使っています。

CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。

私にとってはとても使い易いバージョン管理システムです。

Re:

[Anonymous Coward]

SVKじゃ駄目ですかそうですかorz

>サーバを作る必要がなく

いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。

これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。

>管理ファイルがトップディレクトリだけ

ほーなるほど。それはいい。

これは分散型であることとは原理的には無関係だが、
たぶんみんなここ数年で気付いたことなんだろうね：
「独立したリポジトリ置き場なんて不要じゃん」と。

OldTypeに言わせれば「RCSへの回帰」だな。

Re:

[uni (661)]

ソフトウェア工学屋の端くれです．

「独立したリポジトリ置き場なんて不要じゃん」と。

確かに，複数人での開発において，サーバの設定が不要になるのは利点です．
しかし，同時に，リポジトリが分散してしまうことにより，全ての変更を追跡・管理することが出来なくなるというデメリットが発生します． 少なくとも，企業内で開発している場合には，管理容易性が優先すると思うのですが如何でしょうか．

Re:

[Anonymous Coward]

>ソフトウェア工学屋の端くれ
>企業内で開発している場合には，管理容易性が優先

「管理という名の拘束具」ですね。
縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。

＃といわれたくなければ名乗らなければいいのに。

どちらかというと
「この人員の範囲＋拘束の導入によって出来るだけ開発効率を上げる」
と考えるよりは
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
と考えるほうが、
よほどマシなものが作れるのが目にみえてるのですが。

いや、きっと管理にも良い管理と悪い管理があるんだろうけど、
実際の運用では、俗人性は組織(会社)のある程度の上位に行けば排除不能なので、
どこかで「バカの壁」が出現し、駄目管理にされてしまう可能性が凄く高いんですよ。
それはバカによる駄目実装をされる危険率と本質的には同じ。
そういう意味では「良い管理をすれば」というIFはあまり現実的ではない。

Re:

[uni (661)]

「管理という名の拘束具」ですね。
縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。

＃といわれたくなければ名乗らなければいいのに。

ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです． と言うよりも，今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．

# ほぼ掘り尽くした鉱脈なので，あまり研究にならないんですよね．

「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」

例えば，それを実行するにしても，入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題があり

Re:

[Anonymous Coward]

>ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです．と言うよりも，
>今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．

んなこたぁない、ちょっと調べればいっぱいあるじゃないか。

Re:今はMercurialをメインで使用中

[uni (661)]

>ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです．と言うよりも，
>今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．

んなこたぁない、ちょっと調べればいっぱいあるじゃないか。

「トップダウンなプロセスそのものの研究」という表現が曖昧ですし，「ほとんどいない」というのは言い過ぎでした．
この発言については撤回させていただきたいと思います．