アカウント名:
パスワード:
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
ソフトウェア工学屋の端くれです.
「独立したリポジトリ置き場なんて不要じゃん」と。
確かに,複数人での開発において,サーバの設定が不要になるのは利点です. しかし,同時に,リポジトリが分散してしまうことにより,全ての変更を追跡・管理することが出来なくなるというデメリットが発生します. 少なくとも,企業内で開発している場合には,管理容易性が優先すると思うのですが如何でしょうか.
「管理という名の拘束具」ですね。 縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。 #といわれたくなければ名乗らなければいいのに。
ソフトウェア工学屋と言っても,トップダウンな管理を研究してるわけじゃないです. と言うよりも,今時の研究を見てもらえばわかりますが,トップダウンなプロセスそのものを研究してる人はほとんどいません.
# ほぼ掘り尽くした鉱脈なので,あまり研究にならないんですよね.
「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
例えば,それを実行するにしても,入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね. 定量的な根拠なく実行すれば,更なる混乱を招くだけでしょうし.
そこで,問題になっているのが何なのか (それ以前に,問題が起きているのか) を知るための研究が行なわれています. 例えば,BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります.
しかし,リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが,#1274953 [srad.jp]で書いたことです.
>ソフトウェア工学屋と言っても,トップダウンな管理を研究してるわけじゃないです.と言うよりも, >今時の研究を見てもらえばわかりますが,トップダウンなプロセスそのものを研究してる人はほとんどいません. んなこたぁない、ちょっと調べればいっぱいあるじゃないか。
「トップダウンなプロセスそのものの研究」という表現が曖昧ですし,「ほとんどいない」というのは言い過ぎでした. この発言については撤回させていただきたいと思います.
少なくともMercurialを使った場合、ローカルリポジトリ上の修正履歴は、途中のバージョンを含めて、差分伝播の際にメインリポジトリにも格納されます。それでは問題があるのでしょうか。
メインリポジトリに格納された情報は追跡出来ますね. しかし,実験的に作成したが結局捨ててしまった,あるいはマイナーな要求のための機能であるといった理由で,メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます.
# このような事態が起こりやすくなるというだけで,結局は運用の問題なのですが.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
今はMercurialをメインで使用中 (スコア:5, 参考になる)
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
Re: (スコア:0)
svn を使い出した頃は「すげー、ディレクトリも mv できる」とか
「オフラインで diff できて素敵」って感動したものですが、
hg になったら「svn はダメダメだったな」としか思いません。
分散型であるゆえの機能が意外な落とし穴になることもありますが、
速度や安定性、セットアップの容易さなどを考えると、もう
他の選択肢はありません、うちの場合。
# あとは日本語の文書が整備されれば言うことなしかも。
Re: (スコア:0)
> 分散型であるゆえの機能が意外な落とし穴になることもありますが、
の落とし穴というものを是非教えて下さい。
Re:今はMercurialをメインで使用中 (スコア:2, 参考になる)
Re: (スコア:0)
>サーバを作る必要がなく
いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。
これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。
>管理ファイルがトップディレクトリだけ
ほーなるほど。それはいい。
これは分散型であることとは原理的には無関係だが、
たぶんみんなここ数年で気付いたことなんだろうね:
「独立したリポジトリ置き場なんて不要じゃん」と。
OldTypeに言わせれば「RCSへの回帰」だな。
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)
メインリポジトリに格納された情報は追跡出来ますね.
しかし,実験的に作成したが結局捨ててしまった,あるいはマイナーな要求のための機能であるといった理由で,メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます.
# このような事態が起こりやすくなるというだけで,結局は運用の問題なのですが.
Re: (スコア:0)
ただ複数人で使うとマルチプルヘッドとか、そのマージとか面倒が増える事もありますね。
また半分はソースのバックアップのためだったり、リリースバージョンの管理も必要だったりで
やはり当分はSubversionも必要なのかなーとグルグル考えてしまいます。
Re: (スコア:0)
Git vs Mercurial で悩んでて、結局Mercurialになりました。
決め手は、いろいろあると思うのですが
自分の注目してるオープンソースプロジェクトでの採用だと思います。
( OpenSolaris,OpenJDK,Mozilla )
大規模運用の実績がたまるのは安心です。
あと、個人的にはTeamwareから移行してるプロジェクトが多い点も嬉しい点です。
# TeamwareユーザによるTeamware似の周辺ツールが出てくるかなぁ、と期待
TortoiseHgは期待のアプリなんですが、
認証部分がまだ弱いと思ってるのでpush,pullはコマンドラインで使ってます。
Java開発中は、Netnbeansにプラグインがあるのでそれ経由でcommitまではしています。
# darcs はやっぱインストールが面倒だからはやらなかったのかなぁ