パスワードを忘れた? アカウント作成
17454 story

分散型バージョン管理システムはどれが良い? 44

ストーリー by mhatta
svkはout of 眼中か 部門より

Anonymous Coward曰く、

ゲームエミュレータMAMEをMac OS Xに移植したことで知られるDave Dribin氏が、自身のブログ記事で、分散型のバージョン管理システム(DVCS)を検討しています。Git、Mercurial、Bazaarの三者を比較した結果、氏はMercurialを選んだそうです。GitはWindowsサポートが弱く、Bazaarはただでさえまだ普及していないDVCSの中でもさらにシェアが小さすぎるのが問題だとのこと。

そもそも日本ではまだ(分散型ではない)CVSやSubversionが主流で、DVCSはほとんど普及していないように思いますが、使っている方がおられれば感想を聞かせてください。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ioctl (606) on 2008年01月03日 9時47分 (#1274807)
    バージョン管理システムは、CVS, Subversion, Mercurialと使ってきて、今は新規開発ネタは主にMercurialを使っています。

    CVSやSubversionのように、サーバを作る必要がなく気軽に使えるし、管理ファイルがトップディレクトリだけなのでexportしなくてもtar.gzが作れるし、pythonなので改造し易いし、何よりMercurial patche queuesによるパッチの管理はとても強力です。

    私にとってはとても使い易いバージョン管理システムです。

    • by Anonymous Coward
      やっぱ mercurial (hg) ですよね。

      svn を使い出した頃は「すげー、ディレクトリも mv できる」とか
      「オフラインで diff できて素敵」って感動したものですが、
      hg になったら「svn はダメダメだったな」としか思いません。
      分散型であるゆえの機能が意外な落とし穴になることもありますが、
      速度や安定性、セットアップの容易さなどを考えると、もう
      他の選択肢はありません、うちの場合。

      # あとは日本語の文書が整備されれば言うことなしかも。

    • by Anonymous Coward
      SVKじゃ駄目ですかそうですかorz

      >サーバを作る必要がなく

      いちおうSVNでもサーバは不要だ。リポジトリURLをfile:で運用すればいい。URLはローカルフォルダでもリモートでも構わない。リポジトリの構造が壊れにくいそうなので、それでも大丈夫とのこと。

      これは他のVer管理ツールも同様な実装をすれば良いだけのことではあるが。

      >管理ファイルがトップディレクトリだけ

      ほーなるほど。それはいい。

      これは分散型であることとは原理的には無関係だが、
      たぶんみんなここ数年で気付いたことなんだろうね:
      「独立したリポジトリ置き場なんて不要じゃん」と。

      OldTypeに言わせれば「RCSへの回帰」だな。
      • ソフトウェア工学屋の端くれです.

        「独立したリポジトリ置き場なんて不要じゃん」と。

        確かに,複数人での開発において,サーバの設定が不要になるのは利点です.
        しかし,同時に,リポジトリが分散してしまうことにより,全ての変更を追跡・管理することが出来なくなるというデメリットが発生します. 少なくとも,企業内で開発している場合には,管理容易性が優先すると思うのですが如何でしょうか.

        親コメント
        • by Anonymous Coward on 2008年01月03日 20時53分 (#1274987)
          >ソフトウェア工学屋の端くれ
          >企業内で開発している場合には,管理容易性が優先

          「管理という名の拘束具」ですね。
          縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。

          #といわれたくなければ名乗らなければいいのに。

          どちらかというと
          「この人員の範囲+拘束の導入によって出来るだけ開発効率を上げる」
          と考えるよりは
          「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
          と考えるほうが、
          よほどマシなものが作れるのが目にみえてるのですが。

          いや、きっと管理にも良い管理と悪い管理があるんだろうけど、
          実際の運用では、俗人性は組織(会社)のある程度の上位に行けば排除不能なので、
          どこかで「バカの壁」が出現し、駄目管理にされてしまう可能性が凄く高いんですよ。
          それはバカによる駄目実装をされる危険率と本質的には同じ。
          そういう意味では「良い管理をすれば」というIFはあまり現実的ではない。
          親コメント
          • 「管理という名の拘束具」ですね。
            縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。

            #といわれたくなければ名乗らなければいいのに。

            ソフトウェア工学屋と言っても,トップダウンな管理を研究してるわけじゃないです. と言うよりも,今時の研究を見てもらえばわかりますが,トップダウンなプロセスそのものを研究してる人はほとんどいません.

            # ほぼ掘り尽くした鉱脈なので,あまり研究にならないんですよね.

            「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」

            例えば,それを実行するにしても,入れ替える権限を持った人間が「駄目人材」をどう特定するのかという問題がありますよね. 定量的な根拠なく実行すれば,更なる混乱を招くだけでしょうし.

            そこで,問題になっているのが何なのか (それ以前に,問題が起きているのか) を知るための研究が行なわれています. 例えば,BTSのDBやリポジトリを様々な方法で解析して可視化するなんて研究があります.

            しかし,リポジトリが分散すると解析対象のデータが集めにくくなってしまいまうというのが,#1274953 [srad.jp]で書いたことです.

            親コメント
            • 「ソフトウェア工学屋」って聞いた時点で滝とか RUP とかユースケースとか quantitative metrics じゃなくて、
              背広着て Dilbert のボスみたいな髪型で携帯電話の下請けプログラマを病院送りになるまで酷使してるのを想像してるんじゃないでしょうか。
              親コメント
            • by Anonymous Coward
              >ソフトウェア工学屋と言っても,トップダウンな管理を研究してるわけじゃないです.と言うよりも,
              >今時の研究を見てもらえばわかりますが,トップダウンなプロセスそのものを研究してる人はほとんどいません.

              んなこたぁない、ちょっと調べればいっぱいあるじゃないか。

              • >ソフトウェア工学屋と言っても,トップダウンな管理を研究してるわけじゃないです.と言うよりも,
                >今時の研究を見てもらえばわかりますが,トップダウンなプロセスそのものを研究してる人はほとんどいません.

                んなこたぁない、ちょっと調べればいっぱいあるじゃないか。

                「トップダウンなプロセスそのものの研究」という表現が曖昧ですし,「ほとんどいない」というのは言い過ぎでした.
                この発言については撤回させていただきたいと思います.

                親コメント
          • by Anonymous Coward
            俺はただのソフトウェア屋だけど、

            >>ソフトウェア工学屋の端くれ
            >>企業内で開発している場合には,管理容易性が優先
            >「管理という名の拘束具」ですね。
            >縛れば縛るほど実際には開発効率は落ちるだけなんですけどね。
            >#といわれたくなければ名乗らなければいいのに。

            いったいなんの関係があるんだ?
            アホ管理への批判は結構だが、管理容易性についてはまるで言及がない。
            リポジトリ分散への問題指摘への擁護にまったくなってないぞ?

            それともアホ管理をなくすためには、
            ダメ人材は排除すれば十分と本気で考えているのか?
          • by Anonymous Coward
            >どちらかというと
            >「この人員の範囲+拘束の導入によって出来るだけ開発効率を上げる」
            >と考えるよりは
            >「拘束を出来るだけ減らし、その代わり駄目人材は入れ替えることで、開発効率を稼ぐ」
            >と考えるほうが、
            >よほどマシなものが作れるのが目にみえてるのですが。

            雰囲気は分かるけど具体性が無いし、なんとなく青い鳥症候群だけな気がする。
            現実はいかに良い折衷案を採択していくかの連続だろうから
            遠い理想を夢見るだけじゃあ「何もやらない」という結果に終わるのがオチ。
            それでは進歩は無い。

            ま、大口叩くなら具体案示せよ、というのに尽きる。
            具体案無しではトレードオフの見極めもあったものじゃあない。
        • 少なくともMercurialを使った場合、ローカルリポジトリ上の修正履歴は、途中のバージョンを含めて、差分伝播の際にメインリポジトリにも格納されます。それでは問題があるのでしょうか。
          親コメント
          • 少なくともMercurialを使った場合、ローカルリポジトリ上の修正履歴は、途中のバージョンを含めて、差分伝播の際にメインリポジトリにも格納されます。それでは問題があるのでしょうか。

            メインリポジトリに格納された情報は追跡出来ますね.
            しかし,実験的に作成したが結局捨ててしまった,あるいはマイナーな要求のための機能であるといった理由で,メインリポジトリに格納されなかった情報は追跡出来なくなってしまいます.

            # このような事態が起こりやすくなるというだけで,結局は運用の問題なのですが.

            親コメント
    • by Anonymous Coward
      Mercurial使ってますがEclipseのまともなプラグインが出ればメインで使用しても良さそうには思います。
      ただ複数人で使うとマルチプルヘッドとか、そのマージとか面倒が増える事もありますね。
      また半分はソースのバックアップのためだったり、リリースバージョンの管理も必要だったりで
      やはり当分はSubversionも必要なのかなーとグルグル考えてしまいます。
    • by Anonymous Coward
      同じくMercurialを使い始めてますね。
      Git vs Mercurial で悩んでて、結局Mercurialになりました。

      決め手は、いろいろあると思うのですが
      自分の注目してるオープンソースプロジェクトでの採用だと思います。
      ( OpenSolaris,OpenJDK,Mozilla )
      大規模運用の実績がたまるのは安心です。

      あと、個人的にはTeamwareから移行してるプロジェクトが多い点も嬉しい点です。
      # TeamwareユーザによるTeamware似の周辺ツールが出てくるかなぁ、と期待

      TortoiseHgは期待のアプリなんですが、
      認証部分がまだ弱いと思ってるのでpush,pullはコマンドラインで使ってます。
      Java開発中は、Netnbeansにプラグインがあるのでそれ経由でcommitまではしています。

      # darcs はやっぱインストールが面倒だからはやらなかったのかなぁ
  • 本当の主流 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2008年01月03日 13時32分 (#1274876)
    hoge.c
    hoge.c.bak
    hoge.c.20080103
    とか

    【旧】○○データ.xls
    20071231○○データ.xls
    【新】○○データ.xls
    【最新】○○データ.xls
    とか
    • 親記事のネタはジョークのようで、ジョークになってない職場があるかも知れない。
      ん年前に知人が体験した話なのだが、新しくやってきた上司がVisual SourceSafe(*1)の利用を禁止し、『ファイル名.日付』形式で管理させるようになったそうだ。お陰で現場はどれが最新のファイルかさっぱり分からなくなり、開発効率が大幅に下がったらしい。また、一日に複数のファイルを作った場合には更にわけがわからなくなっていったらしい。「俺達の頃はこれが普通だったから」というのが上司の言い分だったそうだけど、傍から見るとなんでバージョン管理システムがあるのか全く分かってないと思ってしまった。

      # プログラムはちゃんとバージョン管理システムを使うものの、
      # 設定ファイルは親記事のようなまぬけな管理システムを使っているけどIDで orz

      (*1) Visual SourceSafe
      VSSと略される、マイクロソフト社製バージョン管理システム。ロック方式なので、誰かがファイルをいじっていると他の人がそのファイルを操作することは出来ない。
      親コメント
      • >ロック方式なので、誰かがファイルをいじっていると他の人がそのファイルを操作することは出来ない。

        複数チェックアウトモデルってのもサポートしているようで、チェックイン時に衝突があるばあい、マージしてくれます。
        http://msdn2.microsoft.com/ja-jp/library/ms181042(VS.80).aspx [microsoft.com]

        あんまし使わないけど。
      • by Anonymous Coward
        >(*1) Visual SourceSafe
        >VSSと略される、マイクロソフト社製バージョン管理システム。ロック方式なので、誰かがファイルをいじっていると他の人がそのファイルを操作することは出来ない。

        こんなところで反応しても仕方ないんだけど、かなり間違っているので訂正。
        ver6までは基本CheckOut,Modify、CheckInのLock方式だったんだけど、
        設定によってはマルチチェックアウトできるようになっているので
        誰かがいじっていてもほかの人が操作できないなんてことはありません。
        当たり前ですが、複数の人が編集した場合は、CheckInのときにMergeされ
    • by greentea (17971) on 2008年01月04日 0時11分 (#1275026) 日記
      で、謎のバグの原因は
      hogehoge20080102_test.cで修正したはずのところが
      hogehoge20080103.cでは修正されていなかった
      とか、そんなことだったりするわけ?

      # まるでやらかしたことがあるかのようなコメントですな>俺 orz
      --
      1を聞いて0を知れ!
      親コメント
  • by mik_naruto (26947) on 2008年01月03日 18時56分 (#1274963)
    個人的に、分散レポジトリの最大の不安は「過去の更新履歴を全部ローカルにダウンロードしないと作業始まらないのかよー」という点だったりするのですが、そのへんどうでしょう。

    そりゃ更新履歴が全部ローカルにあれば色々嬉しいのは自明っちゃ自明だし、そんな発想が成り立つほどネットワークもストレージも安価になりましたが…
    にしても、某OSのカーネルの100MB程度ならともかく、今うちにある「最新リビジョンが1GBで、リポジトリは1ヶ月で数GB増えた」という画像やDTPデータ主体のSubversionリポジトリが、Hgとかに移行して普通に動いてくれるのか心配です。

    メンバーに未だにテレホユーザという人がいて、分散リポジトリ自体は本来そういう人のためにあるのだと思いますが、彼にとって1GBならギリギリだけど、10GBだと始まる前から終わってます。(リポジトリのpartial cloneができたり、headとログメッセージだけのcloneとかができる?)
    • Mercurialは、バイナリファイルは差分をとってくれないようです。
      そもそも、衝突解消のツールがなければ、バージョン管理はロック方式でないとならないのではないでしょうか。
      親コメント
      • じゃあまだ自分の用途だとSVNを置き換えるのは無理ですね。
        10MBのビットマップの一部のゴミを取り除いただけとか、3MBのDTPファイルの1文字誤植を修正しただけで(差分ではなく)全体が格納されてたんじゃ、うちのSVNの数GBのリポジトリはhgにコンバートした瞬間に更に数倍に膨れそうです。

        というか、あ、hgやSVKには原理上ロックの仕組みそのものがないんですね(まぁ当然素のSVNにはありますが)。うーん分散しすぎるのも困った。マージ履歴とローカルでのコミットだけでも欲しかったのに。
        (バイナリでファイル単位のマージは不可能でも、8割型共通で「関東版」「関東版」でちょっと違う本とかをブランチで管理するときに、共通部分の誤植訂正を追いかけてみたかった)
        親コメント
      • バイナリの差分はとってくれるようです。

        手持ちの xls ファイルを少しいじって commit したところ、およそ50%程度のデータファイルが出来ています。
        そこから更に変更をcommitしていっても極端な大きさにはならないようです。

        ただし素の Mercurial は扱えるファイルサイズの上限が 10MB にハードコーディングされている為、大きなファイルを扱う場合には localrepo.py の該当箇所を適時修正する必要があるでしょう。
        親コメント
  • 会社ではいまだにCVSだ。
    #新しいVCSを導入しようとするとそのリポジトリサーバのお守りを押し付けられるので…。

    個人的にはしばらく前からSubversionを使っているが、ここ数年は分散型が気になって仕方が無い。
    #分散型ならリポジトリサーバは必要ではないので良いかもと思っている。

    Eclipseなどの統合開発環境で簡単に(かつ不具合無く安定して)使えるなら、導入はしやすいと思うけど。
    そこまでちゃんと調べてないのは自分の問題だけどね。
    --
    masamic
  • タレコミ文でWindowsでも使用感がよいように表現されているのは、TortoiseHg [sourceforge.net]があるから(だと思う)。TortoiseSVNと使用感がほとんど変わらないのでオススメです。
    • by Anonymous Coward
      それだけでもないんじゃないかな。

      例えば、unixのツールをcygwinで移植されても、cygwinはioが糞遅いのでioを酷使するアプリは使用感が酷く悪かったりする。

      Mercurialの場合、ベースになるpythonがその辺含めて比較的しっかりサポートされている(ソースにvcのプロジェクトファイルも付いてくる)のが親和性を高めることに役立っているのだと思われ。

      まぁ、gitはシェルスクリプトへの依存とか別の問題もあるからそれ以前のレベルでマイナスからのスタートだったりするけど。
    • by Anonymous Coward
      これはマルチバイト対応は大丈夫なのかな。 以前Windowsでhgを試したときは、案の定「十」とか入ったファイルは操作できなかったんだけど。
  • 一人で開発する場合には分散バージョン管理システム(以下、DVCS)を使う意義は無いのだろうかと少し考えてみた。
    自分が理解した範囲では、分散型と集中型の違いはリポジトリの分割の可否のように思う。
    一人で一台のPCしか使わないなら、そこにリポジトリを置けば分割の必要性は無く、DVCSは不要だろう。
    しかし、複数台のPCを使う場合は、ネットワークの接続性が確保されない限りDVCSが必要そうだ。
    普段はデスクトップPCで作業して、出かけるときにノートPCを持っていく場合、
    ノートPCで開発したソースコードもちゃんとバージョン管理したいだろうから。
    そして、必ずしも出先でネットワークに繋がるとは限らないだろうから。
    お小遣いの少ない学生だとb-mobileなどは買えないですからね。

    まあ、自分だったら一段落すると開発への興味を失ってしまうので、DVCSはそれ程要らなそうな気がするけど...
    というか、皆さん、どういうときcommitしますか?
    • たとえば、とあるスクリプト集(たとえばxoops)を使っていて、
      オフィシャルリリースに、3rdパーティーのパッチをあてて、さらに自分で改変していると、
      オフィシャルやパッチのリリース毎に変更をmergeしていくのがとても大変です。
      このへんをスムーズに管理するために、一人でもバージョン管理システムが役に立つと思います。

      しかし、集中型か分散型かによって、mergeの手間に変化があるのでしょうか?
      日本語のチュートリアルを読みましたが、subversionとの違いがわかりませんでした。
      一人で使う場合にも、分散型を使うメリットってありますか?
      親コメント
      • by Anonymous Coward
        一人でも超大規模になれば、分散型のメリットは得られます。まあ、ほぼありえない仮定ですが。
        Mercurialは、導入容易性という点で非常に優秀なので、その意味で個人利用におすすめだったりしますが。

        分散型のメリットを最も受けられるのは、不特定多数が参加するバザール型開発だと思います。
        企業など、参加者を特定しやすい環境であれば、集中管理型で十分な場合の方が多いでしょう。
        #Googleのようにプロジェクト外の人がpatcheを送れる環境ならまた違うでしょうが

        ただ企業内でも、大は小を兼ねると言う事で、分散型を集中型として使うという手はあります。
        これなら、分かっている人は個人リポジトリを作れますし、良く分からない人はこれまで通り、
        メインリポジトリにコミットするだけです。
    • 個人的には職場でのノートでの作業が中心で、時々、他につなぎ替えることのできない、特定業務用の機器から出てくる出力を扱わないといけなくて、また自宅でも作業をする場合があるような環境にいます。この記事を見てMercurialを使い始めましたが、なるほど、これは便利。
      これまではSubversionを使っていましたが、職場常置、ノート、自宅の三台の同期をキープするのがなかなかややこしかったのですが、ノート経由でこれらの同期がとれるので便利ですね。Subversionでも、ノートをサーバにして、同期取ればできないことはないのかも知れませんが、一番リソースが少ないマシンであることもあってその気にはならなかったんですよね。

      後、万が一どれかが使用不可になった場合でも、比較的簡単に他のマシンとリムーバルメディアなど経由で同期を保てそうなので、その点ではある程度の耐障害性としてのメリットも期待できるのではないかと思います。
      親コメント
    • by Anonymous Coward
      ネットワークでつながっていない2個所で、それぞれDVCSのリポジトリ作っても
      それぞれ独立に変更が記録されるだけで、マージは手でやらないと駄目ですよ?

      その時に、ネットワークでつながっていないならどうやって搬送するかとか
      どの差分までが取り込まれてるかとか、どの差分は取り込む必要がないかとかは
      全部自分で考えて自分で管理しないと駄目ですよ?

      同期しなくてもいい人向けじゃなかろか
      • by Anonymous Coward
        一番シンプルな、ただ更新ログ残したいだけの用途の場合、
        SVNだと
        「出かける前に更新しておき、出先で編集したものはコミットできず、自宅に帰ってから全部まとめて家のサーバにコミット」
        という作業の流れだったものが、DVCSだと
        「出かける前に同期しておき、出先で編集したものを時々コミットできて、自宅に帰ってから全部まとめて家のリポジトリに同期」
        という作業の流れに変わるだけで、1人開発でブランチも衝突もない状況なら作業量に何の違いもない…んですよね? 合ってます?
  • 仕事では CVS と Subversion,個人では Subversion を使っています.
    git なんかの分散型も気になるけど,まだ手を出すことができないでいます.
    CVS と Subversion を使っていて欠点だなぁと思うのはやはりマージ作業を
    ほとんど支援してくれないという点です.

    git も Mercurial も実際には使ったことがなく,これから試してみようかな
    というところなんですが,分散型かどうかという点よりもむしろ
    マージ作業がどの程度楽になるのか,という点が気になります.
    そんな今日この頃ですが darcs [darcs.net] も気になっているところ.
    Haskell で記述されているという点や作者が物理学者 [darcs.net]であるところなどが
    なんとなく興味をそそられるところ.

    #ところてんは黒蜜派
    --
    屍体メモ [windy.cx]
    • by nox_dot (11614) on 2008年01月04日 0時16分 (#1275027) 日記
      mergeは、別途mergeツールを使うようです。
      RCSのmergeコマンドや、diffutilsの diff3 -m でだめなら、
      emacsのediffモードなどで手動解決するしかなさそうです。
      親コメント
    • by ksada (4435) on 2008年01月05日 0時59分 (#1275467)
      mercurialのマージは、設定がいりますが、diff3を適切に呼び出すことでcvsやsubversion相当の動作にできます。
      私の感じる大きな相違点はチェンジセットがあることで、cvsやsubversionでは枝がディレクトリに相当し、どれからどれが分岐したというのはユーザが把握してマージする枝とリビジョンを指定する必要がありますが、mercurialでは枝がディレクトリ構成と独立しているので、システムでツリーを確認してリビジョンを指定するだけでマージができます。
      これがあるとちょっとcvsはもとよりsubversionにも戻り難い。
      問題点は、同一ファイルのリビジョン間は差分で格納するのですが、コピー、移動およびリネームの際には丸ごとの実体が追加されてしまい、リポジトリ容量が増加します。
      大規模プロジェクトで構成をバンバン変更する場合は要検討と思われます。
      親コメント
  • 導入が楽とか使いやすいとかも重要なんですが、現行のCVSやSubversion(に限った話でもないけど)のリポジトリから楽に移行かどうかも気になるところです。
    • by Anonymous Coward
      CVSとSVNに関しては、ほぼ全てのソフトで移行ツールが存在しています。
      リポジトリの移行より、人間の移行の方が大変かも。
      学習コストの8割は、変化を嫌がる心との対決に費やされますから。
typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...