アカウント名:
パスワード:
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
ソフトウェア工学屋の端くれです．
「独立したリポジトリ置き場なんて不要じゃん」と。
確かに，複数人での開発において，サーバの設定が不要になるのは利点です． しかし，同時に，リポジトリが分散してしまうことにより，全ての変更を追跡・管理することが出来なくなるというデメリットが発生します． 少なくとも，企業内で開発している場合には，管理容易性が優先すると思うのですが如何でしょうか．
「管理という名の拘束具」ですね。 縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。 ＃といわれたくなければ名乗らなければいいのに。
ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです． と言うよりも，今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
# ほぼ掘り尽くした鉱脈なので，あまり研究にならないんですよね．
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
例えば，それを実行するにしても，入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね． 定量的な根拠なく実行すれば，更なる混乱を招くだけでしょうし．
そこで，問題になっているのが何なのか (それ以前に，問題が起きているのか) を知るための研究が行なわれています． 例えば，BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります．
しかし，リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが，#1274953 [srad.jp]で書いたことです．
>ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです．と言うよりも， >今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません． んなこたぁない、ちょっと調べればいっぱいあるじゃないか。
「トップダウンなプロセスそのものの研究」という表現が曖昧ですし，「ほとんどいない」というのは言い過ぎでした． この発言については撤回させていただきたいと思います．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
今はMercurialをメインで使用中 (スコア:5, 参考になる)
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
Re: (スコア:0)
>サーバを作る必要がなく
いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。
これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。
>管理ファイルがトップディレクトリだけ
ほーなるほど。それはいい。
これは分散型であることとは原理的には無関係だが、
たぶんみんなここ数年で気付いたことなんだろうね：
「独立したリポジトリ置き場なんて不要じゃん」と。
OldTypeに言わせれば「RCSへの回帰」だな。
Re: (スコア:1)
ソフトウェア工学屋の端くれです．
確かに，複数人での開発において，サーバの設定が不要になるのは利点です．
しかし，同時に，リポジトリが分散してしまうことにより，全ての変更を追跡・管理することが出来なくなるというデメリットが発生します． 少なくとも，企業内で開発している場合には，管理容易性が優先すると思うのですが如何でしょうか．
Re: (スコア:1, すばらしい洞察)
>企業内で開発している場合には，管理容易性が優先
「管理という名の拘束具」ですね。
縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。
＃といわれたくなければ名乗らなければいいのに。
どちらかというと
「この人員の範囲＋拘束の導入によって出来るだけ開発効率を上げる」
と考えるよりは
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
と考えるほうが、
よほどマシなものが作れるのが目にみえてるのですが。
いや、きっと管理にも良い管理と悪い管理があるんだろうけど、
実際の運用では、俗人性は組織(会社)のある程度の上位に行けば排除不能なので、
どこかで「バカの壁」が出現し、駄目管理にされてしまう可能性が凄く高いんですよ。
それはバカによる駄目実装をされる危険率と本質的には同じ。
そういう意味では「良い管理をすれば」というIFはあまり現実的ではない。
Re:今はMercurialをメインで使用中 (スコア:1)
ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです． と言うよりも，今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
# ほぼ掘り尽くした鉱脈なので，あまり研究にならないんですよね．
例えば，それを実行するにしても，入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね． 定量的な根拠なく実行すれば，更なる混乱を招くだけでしょうし．
そこで，問題になっているのが何なのか (それ以前に，問題が起きているのか) を知るための研究が行なわれています． 例えば，BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります．
しかし，リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが，#1274953 [srad.jp]で書いたことです．
Re:今はMercurialをメインで使用中 (スコア:1)
背広着て Dilbert のボスみたいな髪型で携帯電話の下請けプログラマを病院送りになるまで酷使してるのを想像してるんじゃないでしょうか。
Re: (スコア:0)
>今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
んなこたぁない、ちょっと調べればいっぱいあるじゃないか。
Re:今はMercurialをメインで使用中 (スコア:1)
「トップダウンなプロセスそのものの研究」という表現が曖昧ですし，「ほとんどいない」というのは言い過ぎでした．
この発言については撤回させていただきたいと思います．