アカウント名:
パスワード:
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
ソフトウェア工学屋の端くれです．
「独立したリポジトリ置き場なんて不要じゃん」と。
確かに，複数人での開発において，サーバの設定が不要になるのは利点です． しかし，同時に，リポジトリが分散してしまうことにより，全ての変更を追跡・管理することが出来なくなるというデメリットが発生します． 少なくとも，企業内で開発している場合には，管理容易性が優先すると思うのですが如何でしょうか．
「管理という名の拘束具」ですね。 縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。 ＃といわれたくなければ名乗らなければいいのに。
ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです． と言うよりも，今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
# ほぼ掘り尽くした鉱脈なので，あまり研究にならないんですよね．
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
例えば，それを実行するにしても，入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね． 定量的な根拠なく実行すれば，更なる混乱を招くだけでしょうし．
そこで，問題になっているのが何なのか (それ以前に，問題が起きているのか) を知るための研究が行なわれています． 例えば，BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります．
しかし，リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが，#1274953 [srad.jp]で書いたことです．
>ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです．と言うよりも， >今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません． んなこたぁない、ちょっと調べればいっぱいあるじゃないか。
「トップダウンなプロセスそのものの研究」という表現が曖昧ですし，「ほとんどいない」というのは言い過ぎでした． この発言については撤回させていただきたいと思います．
少なくともMercurialを使った場合、ローカルリポジトリ上の修正履歴は、途中のバージョンを含めて、差分伝播の際にメインリポジトリにも格納されます。それでは問題があるのでしょうか。
メインリポジトリに格納された情報は追跡出来ますね． しかし，実験的に作成したが結局捨ててしまった，あるいはマイナーな要求のための機能であるといった理由で，メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます．
# このような事態が起こりやすくなるというだけで，結局は運用の問題なのですが．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
今はMercurialをメインで使用中 (スコア:5, 参考になる)
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
Re:今はMercurialをメインで使用中 (スコア:0)
>サーバを作る必要がなく
いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。
これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。
>管理ファイルがトップディレクトリだけ
ほーなるほど。それはいい。
これは分散型であることとは原理的には無関係だが、
たぶんみんなここ数年で気付いたことなんだろうね：
「独立したリポジトリ置き場なんて不要じゃん」と。
OldTypeに言わせれば「RCSへの回帰」だな。
ただ、上記のようにSVNでもfile:でトップ辺りをリポジトリ置き場にすれば、同じことだが。
>pythonなので改造し易い
そういえば、
Webサイト上つまりCGI等によって
CMSだのWikiだのソースリポジトリだのを運用するとき、
そのCGIを書いてる言語(Perl/Ruby/…)で実装されたVer管理ツールがもし有れば、
そのまま地続きで使えるのになあ、と思い悩んだことが有った。
もしかしてMercurialもそうやってPythonベースなWebアプリの中に埋め込んだりしますか？
Re:今はMercurialをメインで使用中 (スコア:1)
ソフトウェア工学屋の端くれです．
確かに，複数人での開発において，サーバの設定が不要になるのは利点です．
しかし，同時に，リポジトリが分散してしまうことにより，全ての変更を追跡・管理することが出来なくなるというデメリットが発生します． 少なくとも，企業内で開発している場合には，管理容易性が優先すると思うのですが如何でしょうか．
Re:今はMercurialをメインで使用中 (スコア:1, すばらしい洞察)
>企業内で開発している場合には，管理容易性が優先
「管理という名の拘束具」ですね。
縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。
＃といわれたくなければ名乗らなければいいのに。
どちらかというと
「この人員の範囲＋拘束の導入によって出来るだけ開発効率を上げる」
と考えるよりは
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
と考えるほうが、
よほどマシなものが作れるのが目にみえてるのですが。
いや、きっと管理にも良い管理と悪い管理があるんだろうけど、
実際の運用では、俗人性は組織(会社)のある程度の上位に行けば排除不能なので、
どこかで「バカの壁」が出現し、駄目管理にされてしまう可能性が凄く高いんですよ。
それはバカによる駄目実装をされる危険率と本質的には同じ。
そういう意味では「良い管理をすれば」というIFはあまり現実的ではない。
Re:今はMercurialをメインで使用中 (スコア:1)
ソフトウェア工学屋と言っても，トップダウンな管理を研究してるわけじゃないです． と言うよりも，今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
# ほぼ掘り尽くした鉱脈なので，あまり研究にならないんですよね．
例えば，それを実行するにしても，入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね． 定量的な根拠なく実行すれば，更なる混乱を招くだけでしょうし．
そこで，問題になっているのが何なのか (それ以前に，問題が起きているのか) を知るための研究が行なわれています． 例えば，BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります．
しかし，リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが，#1274953 [srad.jp]で書いたことです．
Re:今はMercurialをメインで使用中 (スコア:1)
背広着て Dilbert のボスみたいな髪型で携帯電話の下請けプログラマを病院送りになるまで酷使してるのを想像してるんじゃないでしょうか。
Re: (スコア:0)
>今時の研究を見てもらえばわかりますが，トップダウンなプロセスそのものを研究してる人はほとんどいません．
んなこたぁない、ちょっと調べればいっぱいあるじゃないか。
Re:今はMercurialをメインで使用中 (スコア:1)
「トップダウンなプロセスそのものの研究」という表現が曖昧ですし，「ほとんどいない」というのは言い過ぎでした．
この発言については撤回させていただきたいと思います．
Re: (スコア:0)
>>ソフトウェア工学屋の端くれ
>>企業内で開発している場合には，管理容易性が優先
>「管理という名の拘束具」ですね。
>縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。
>＃といわれたくなければ名乗らなければいいのに。
いったいなんの関係があるんだ？
アホ管理への批判は結構だが、管理容易性についてはまるで言及がない。
リポジトリ分散への問題指摘への擁護にまったくなってないぞ？
それともアホ管理をなくすためには、
ダメ人材は排除すれば十分と本気で考えているのか？
Re: (スコア:0)
>「この人員の範囲＋拘束の導入によって出来るだけ開発効率を上げる」
>と考えるよりは
>「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
>と考えるほうが、
>よほどマシなものが作れるのが目にみえてるのですが。
雰囲気は分かるけど具体性が無いし、なんとなく青い鳥症候群だけな気がする。
現実はいかに良い折衷案を採択していくかの連続だろうから
遠い理想を夢見るだけじゃあ「何もやらない」という結果に終わるのがオチ。
それでは進歩は無い。
ま、大口叩くなら具体案示せよ、というのに尽きる。
具体案無しではトレードオフの見極めもあったものじゃあない。
Re:今はMercurialをメインで使用中 (スコア:1)
Re:今はMercurialをメインで使用中 (スコア:1)
メインリポジトリに格納された情報は追跡出来ますね．
しかし，実験的に作成したが結局捨ててしまった，あるいはマイナーな要求のための機能であるといった理由で，メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます．
# このような事態が起こりやすくなるというだけで，結局は運用の問題なのですが．