アカウント名:
パスワード:
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
ソフトウェア工学屋の端くれです.
「独立したリポジトリ置き場なんて不要じゃん」と。
確かに,複数人での開発において,サーバの設定が不要になるのは利点です. しかし,同時に,リポジトリが分散してしまうことにより,全ての変更を追跡・管理することが出来なくなるというデメリットが発生します. 少なくとも,企業内で開発している場合には,管理容易性が優先すると思うのですが如何でしょうか.
少なくともMercurialを使った場合、ローカルリポジトリ上の修正履歴は、途中のバージョンを含めて、差分伝播の際にメインリポジトリにも格納されます。それでは問題があるのでしょうか。
メインリポジトリに格納された情報は追跡出来ますね. しかし,実験的に作成したが結局捨ててしまった,あるいはマイナーな要求のための機能であるといった理由で,メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます.
# このような事態が起こりやすくなるというだけで,結局は運用の問題なのですが.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
今はMercurialをメインで使用中 (スコア:5, 参考になる)
CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。
私にとってはとても使い易いバージョン管理システムです。
Re: (スコア:0)
>サーバを作る必要がなく
いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。
これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。
>管理ファイルがトップディレクトリだけ
ほーなるほど。それはいい。
これは分散型であることとは原理的には無関係だが、
たぶんみんなここ数年で気付いたことなんだろうね:
「独立したリポジトリ置き場なんて不要じゃん」と。
OldTypeに言わせれば「RCSへの回帰」だな。
Re: (スコア:1)
ソフトウェア工学屋の端くれです.
確かに,複数人での開発において,サーバの設定が不要になるのは利点です.
しかし,同時に,リポジトリが分散してしまうことにより,全ての変更を追跡・管理することが出来なくなるというデメリットが発生します. 少なくとも,企業内で開発している場合には,管理容易性が優先すると思うのですが如何でしょうか.
Re: (スコア:1)
Re:今はMercurialをメインで使用中 (スコア:1)
メインリポジトリに格納された情報は追跡出来ますね.
しかし,実験的に作成したが結局捨ててしまった,あるいはマイナーな要求のための機能であるといった理由で,メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます.
# このような事態が起こりやすくなるというだけで,結局は運用の問題なのですが.