分散型バージョン管理システムはどれが良い? 44
ストーリー by mhatta
svkはout of 眼中か 部門より
svkはout of 眼中か 部門より
Anonymous Coward曰く、
ゲームエミュレータMAMEをMac OS Xに移植したことで知られるDave Dribin氏が、自身のブログ記事で、分散型のバージョン管理システム(DVCS)を検討しています。Git、Mercurial、Bazaarの三者を比較した結果、氏はMercurialを選んだそうです。GitはWindowsサポートが弱く、Bazaarはただでさえまだ普及していないDVCSの中でもさらにシェアが小さすぎるのが問題だとのこと。
そもそも日本ではまだ(分散型ではない)CVSやSubversionが主流で、DVCSはほとんど普及していないように思いますが、使っている方がおられれば感想を聞かせてください。
今は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 はやっぱインストールが面倒だからはやらなかったのかなぁ
本当の主流 (スコア:3, すばらしい洞察)
hoge.c.bak
hoge.c.20080103
とか
【旧】○○データ.xls
20071231○○データ.xls
【新】○○データ.xls
【最新】○○データ.xls
とか
懐古趣味のボスがいると強要されるかもよ (スコア:3, 参考になる)
ん年前に知人が体験した話なのだが、新しくやってきた上司がVisual SourceSafe(*1)の利用を禁止し、『ファイル名.日付』形式で管理させるようになったそうだ。お陰で現場はどれが最新のファイルかさっぱり分からなくなり、開発効率が大幅に下がったらしい。また、一日に複数のファイルを作った場合には更にわけがわからなくなっていったらしい。「俺達の頃はこれが普通だったから」というのが上司の言い分だったそうだけど、傍から見るとなんでバージョン管理システムがあるのか全く分かってないと思ってしまった。
＃ プログラムはちゃんとバージョン管理システムを使うものの、
＃ 設定ファイルは親記事のようなまぬけな管理システムを使っているけどIDで orz
(*1) Visual SourceSafe
VSSと略される、マイクロソフト社製バージョン管理システム。ロック方式なので、誰かがファイルをいじっていると他の人がそのファイルを操作することは出来ない。
Visual SourceSafeの複数チェックアウトモデル (スコア:0)
複数チェックアウトモデルってのもサポートしているようで、チェックイン時に衝突があるばあい、マージしてくれます。
http://msdn2.microsoft.com/ja-jp/library/ms181042(VS.80).aspx [microsoft.com]
あんまし使わないけど。
Re: (スコア:0)
>VSSと略される、マイクロソフト社製バージョン管理システム。ロック方式なので、誰かがファイルをいじっていると他の人がそのファイルを操作することは出来ない。
こんなところで反応しても仕方ないんだけど、かなり間違っているので訂正。
ver6までは基本CheckOut,Modify、CheckInのLock方式だったんだけど、
設定によってはマルチチェックアウトできるようになっているので
誰かがいじっていてもほかの人が操作できないなんてことはありません。
当たり前ですが、複数の人が編集した場合は、CheckInのときにMergeされ
Re:本当の主流 (スコア:1)
hogehoge20080102_test.cで修正したはずのところが
hogehoge20080103.cでは修正されていなかった
とか、そんなことだったりするわけ？
# まるでやらかしたことがあるかのようなコメントですな>俺 orz
1を聞いて0を知れ!
バイナリ中心で使えます? (スコア:3, 興味深い)
そりゃ更新履歴が全部ローカルにあれば色々嬉しいのは自明っちゃ自明だし、そんな発想が成り立つほどネットワークもストレージも安価になりましたが…
にしても、某OSのカーネルの100MB程度ならともかく、今うちにある「最新リビジョンが1GBで、リポジトリは1ヶ月で数GB増えた」という画像やDTPデータ主体のSubversionリポジトリが、Hgとかに移行して普通に動いてくれるのか心配です。
メンバーに未だにテレホユーザという人がいて、分散リポジトリ自体は本来そういう人のためにあるのだと思いますが、彼にとって1GBならギリギリだけど、10GBだと始まる前から終わってます。(リポジトリのpartial cloneができたり、headとログメッセージだけのcloneとかができる?)
Re:バイナリ中心で使えます? (スコア:1)
そもそも、衝突解消のツールがなければ、バージョン管理はロック方式でないとならないのではないでしょうか。
Re:バイナリ中心で使えます? (スコア:1)
10MBのビットマップの一部のゴミを取り除いただけとか、3MBのDTPファイルの1文字誤植を修正しただけで(差分ではなく)全体が格納されてたんじゃ、うちのSVNの数GBのリポジトリはhgにコンバートした瞬間に更に数倍に膨れそうです。
というか、あ、hgやSVKには原理上ロックの仕組みそのものがないんですね(まぁ当然素のSVNにはありますが)。うーん分散しすぎるのも困った。マージ履歴とローカルでのコミットだけでも欲しかったのに。
(バイナリでファイル単位のマージは不可能でも、8割型共通で「関東版」「関東版」でちょっと違う本とかをブランチで管理するときに、共通部分の誤植訂正を追いかけてみたかった)
Re:バイナリ中心で使えます? (スコア:1)
手持ちの xls ファイルを少しいじって commit したところ、およそ50%程度のデータファイルが出来ています。
そこから更に変更をcommitしていっても極端な大きさにはならないようです。
ただし素の Mercurial は扱えるファイルサイズの上限が 10MB にハードコーディングされている為、大きなファイルを扱う場合には localrepo.py の該当箇所を適時修正する必要があるでしょう。
Re:バイナリ中心で使えます? (スコア:2, 参考になる)
10MB超えると警告は出ますが、そのまま普通にCommitかければ通りますが･･････。
（100MB超のファイルでも問題ありませんでした。）
Re:バイナリ中心で使えます? (スコア:1)
警告と上限を勘違いしていたようです。
次は分散型を使おうと考えているが… (スコア:1)
＃新しいVCSを導入しようとするとそのリポジトリサーバのお守りを押し付けられるので…。
個人的にはしばらく前からSubversionを使っているが、ここ数年は分散型が気になって仕方が無い。
＃分散型ならリポジトリサーバは必要ではないので良いかもと思っている。
Eclipseなどの統合開発環境で簡単に（かつ不具合無く安定して）使えるなら、導入はしやすいと思うけど。
そこまでちゃんと調べてないのは自分の問題だけどね。
masamic
FYI: TortoiseHg (スコア:1)
Re: (スコア:0)
例えば、unixのツールをcygwinで移植されても、cygwinはioが糞遅いのでioを酷使するアプリは使用感が酷く悪かったりする。
Mercurialの場合、ベースになるpythonがその辺含めて比較的しっかりサポートされている(ソースにvcのプロジェクトファイルも付いてくる)のが親和性を高めることに役立っているのだと思われ。
まぁ、gitはシェルスクリプトへの依存とか別の問題もあるからそれ以前のレベルでマイナスからのスタートだったりするけど。
Re: (スコア:0)
分散バージョン管理システムを一人で使う利点は？ (スコア:1)
自分が理解した範囲では、分散型と集中型の違いはリポジトリの分割の可否のように思う。
一人で一台のPCしか使わないなら、そこにリポジトリを置けば分割の必要性は無く、DVCSは不要だろう。
しかし、複数台のPCを使う場合は、ネットワークの接続性が確保されない限りDVCSが必要そうだ。
普段はデスクトップPCで作業して、出かけるときにノートPCを持っていく場合、
ノートPCで開発したソースコードもちゃんとバージョン管理したいだろうから。
そして、必ずしも出先でネットワークに繋がるとは限らないだろうから。
お小遣いの少ない学生だとb-mobileなどは買えないですからね。
まあ、自分だったら一段落すると開発への興味を失ってしまうので、DVCSはそれ程要らなそうな気がするけど...
というか、皆さん、どういうときcommitしますか？
Re:分散バージョン管理システムを一人で使う利点は？ (スコア:1)
オフィシャルリリースに、3rdパーティーのパッチをあてて、さらに自分で改変していると、
オフィシャルやパッチのリリース毎に変更をmergeしていくのがとても大変です。
このへんをスムーズに管理するために、一人でもバージョン管理システムが役に立つと思います。
しかし、集中型か分散型かによって、mergeの手間に変化があるのでしょうか?
日本語のチュートリアルを読みましたが、subversionとの違いがわかりませんでした。
一人で使う場合にも、分散型を使うメリットってありますか?
Re: (スコア:0)
Mercurialは、導入容易性という点で非常に優秀なので、その意味で個人利用におすすめだったりしますが。
分散型のメリットを最も受けられるのは、不特定多数が参加するバザール型開発だと思います。
企業など、参加者を特定しやすい環境であれば、集中管理型で十分な場合の方が多いでしょう。
#Googleのようにプロジェクト外の人がpatcheを送れる環境ならまた違うでしょうが
ただ企業内でも、大は小を兼ねると言う事で、分散型を集中型として使うという手はあります。
これなら、分かっている人は個人リポジトリを作れますし、良く分からない人はこれまで通り、
メインリポジトリにコミットするだけです。
Re: (スコア:0)
Re:分散バージョン管理システムを一人で使う利点は？ (スコア:1)
これまではSubversionを使っていましたが、職場常置、ノート、自宅の三台の同期をキープするのがなかなかややこしかったのですが、ノート経由でこれらの同期がとれるので便利ですね。Subversionでも、ノートをサーバにして、同期取ればできないことはないのかも知れませんが、一番リソースが少ないマシンであることもあってその気にはならなかったんですよね。
後、万が一どれかが使用不可になった場合でも、比較的簡単に他のマシンとリムーバルメディアなど経由で同期を保てそうなので、その点ではある程度の耐障害性としてのメリットも期待できるのではないかと思います。
Re: (スコア:0)
それぞれ独立に変更が記録されるだけで、マージは手でやらないと駄目ですよ？
その時に、ネットワークでつながっていないならどうやって搬送するかとか
どの差分までが取り込まれてるかとか、どの差分は取り込む必要がないかとかは
全部自分で考えて自分で管理しないと駄目ですよ？
同期しなくてもいい人向けじゃなかろか
Re: (スコア:0)
SVNだと
「出かける前に更新しておき、出先で編集したものはコミットできず、自宅に帰ってから全部まとめて家のサーバにコミット」
という作業の流れだったものが、DVCSだと
「出かける前に同期しておき、出先で編集したものを時々コミットできて、自宅に帰ってから全部まとめて家のリポジトリに同期」
という作業の流れに変わるだけで、1人開発でブランチも衝突もない状況なら作業量に何の違いもない…んですよね? 合ってます?
darcs が気になる (スコア:1)
git なんかの分散型も気になるけど，まだ手を出すことができないでいます．
CVS と Subversion を使っていて欠点だなぁと思うのはやはりマージ作業を
ほとんど支援してくれないという点です．
git も Mercurial も実際には使ったことがなく，これから試してみようかな
というところなんですが，分散型かどうかという点よりもむしろ
マージ作業がどの程度楽になるのか，という点が気になります．
そんな今日この頃ですが darcs [darcs.net] も気になっているところ．
Haskell で記述されているという点や作者が物理学者 [darcs.net]であるところなどが
なんとなく興味をそそられるところ．
＃ところてんは黒蜜派
屍体メモ [windy.cx]
Re:darcs が気になる (スコア:2, 参考になる)
RCSのmergeコマンドや、diffutilsの diff3 -m でだめなら、
emacsのediffモードなどで手動解決するしかなさそうです。
Re:darcs が気になる (スコア:2, 参考になる)
私の感じる大きな相違点はチェンジセットがあることで、cvsやsubversionでは枝がディレクトリに相当し、どれからどれが分岐したというのはユーザが把握してマージする枝とリビジョンを指定する必要がありますが、mercurialでは枝がディレクトリ構成と独立しているので、システムでツリーを確認してリビジョンを指定するだけでマージができます。
これがあるとちょっとcvsはもとよりsubversionにも戻り難い。
問題点は、同一ファイルのリビジョン間は差分で格納するのですが、コピー、移動およびリネームの際には丸ごとの実体が追加されてしまい、リポジトリ容量が増加します。
大規模プロジェクトで構成をバンバン変更する場合は要検討と思われます。
現行リポジトリの移行のしやすさは？ (スコア:1)
Re: (スコア:0)
リポジトリの移行より、人間の移行の方が大変かも。
学習コストの8割は、変化を嫌がる心との対決に費やされますから。