[解決済み] Git、Mercurial、Bazaarの相対的な長所と短所は何ですか？[クローズド］

質問

ここにいる人たちは、Git、Mercurial、Bazaarの相対的な長所と短所をどのように見ていますか？

それぞれを互いに、またSVNやPerforceのようなバージョン管理システムに対して検討する場合、どのような問題を考慮すべきでしょうか？

SVNからこれらの分散型バージョン管理システムへの移行を計画する場合、どのような要素を考慮しますか？

どのように解決しますか?

Git は非常に高速で、非常によくスケールし、その概念について非常に透明性があります。このマイナス面は、比較的急な学習曲線があることです。Win32 のポートが利用可能ですが、第一級市民とまではいきません。Gitはユーザーにバージョン番号としてハッシュを公開します。これは保証を提供しますが（単一のハッシュが常に全く同じコンテンツを参照するという意味で、攻撃者は検出されずに履歴を変更できません）、ユーザーにとっては面倒なことかもしれません。Gitは、ファイルの中身がファイル間を移動しても追跡するというユニークな概念を持っており、ファイルを第一レベルのオブジェクトとして見ますが、ディレクトリは追跡しません。gitのもう一つの問題は、多くの操作（例えば リベース のような）多くの操作があり、履歴を簡単に変更できることです（ある意味、ハッシュによって参照されるコンテンツは決して変わりませんが、そのハッシュへの参照は失われる可能性があります）。

Bazaar は適度に速く (浅い履歴を持つツリーでは非常に速いですが、現在のところ履歴の長さではうまくいきません)、従来の SCM (CVS や SVN など) のコマンドライン インターフェイスに慣れている人には習得しやすいものです。Win32は、その開発チームによって第一級のターゲットと見なされています。これは、異なるコンポーネントのためのプラグイン可能なアーキテクチャを持ち、そのストレージフォーマットを頻繁に交換します。これにより、彼らは新しい機能（異なる概念に基づくリビジョン管理システムとの統合のためのより良いサポートなど）を導入し、パフォーマンスを向上させることができるのです。Bazaar チームはディレクトリ追跡とリネームサポートを第一級の機能として考えています。グローバルに一意な revision-id 識別子はすべてのリビジョンで利用できますが、ツリーローカルな revnos（標準リビジョン番号、svn やより一般的な SCM で使用されるものに近い）は、リビジョン識別のためにコンテンツハッシュの代わりに使用されま す。Bazaar は、履歴がローカルシステムにコピーされる代わりにリモートサーバーに保持され、必要なときにネットワーク経由で自動的に参照される "lightweight checkouts" のサポートを持っています。

しかし、bzr-svn は git-svn よりもかなり高機能で、その主な理由はこの目的のために導入されたバックエンド形式のリビジョンにあります。 [2014年現在、更新中。サードパーティの商用製品である SubGit は、SVN と Git の間の双方向インターフェースを提供しており、その忠実度は bzr-svn に匹敵し、かなり洗練されている; I 強く 予算とライセンスの制約が許すならば、git-svn よりもその使用を強くお勧めします]。

Mercurial は、Git のようにリビジョンのコンテンツハッシュアドレスを持つこと、また Git のようにディレクトリをファーストクラスのオブジェクトとして扱わない（そして空のディレクトリを保存できない）こと以外は、広範囲に使ったことがないので、詳細にはコメントできません。しかし、Git以外のどのDSCMよりも高速で、IDEとの統合（特にEclipse）も競合他社よりはるかに優れています。そのパフォーマンス特性(Gitにわずかに劣る)と、優れたクロスプラットフォームとIDEサポートを考えると、Mercurialは、win32中心あるいはIDE中心のメンバーが多いチームにとって、魅力的な存在となるかもしれません。

SVN からの移行における 1 つの懸念は、SVN の GUI フロントエンドと IDE 統合が、分散 SCM のどれよりも成熟していることです。また、現在 SVN でプレコミットスクリプトの自動化 (コミットを続行する前にユニットテストの合格を要求するなど) を多用している場合、おそらく以下のようなツールを使用したいと思うことでしょう。 PQM のようなツールを使用して、共有ブランチへのマージ要求を自動化したいと思うでしょう。

SVK はバックストアとして Subversion を使用する DSCM で、SVN 中心のツールとの統合が非常にうまくできています。しかし、他の主要な DSCM (Darcs も) よりもパフォーマンスとスケーラビリティ特性が劇的に悪く、履歴の長さやファイル数の点で大きくなりがちなプロジェクトでは避けるべきでしょう。

[著者について 私は仕事ではGitとPerforceを、個人的なプロジェクトや組み込みライブラリではBazaarを使用しています。前職ではSVNを中心に大量の自動化を構築していました。それ以前にはGNU Arch、BitKeeper、CVSなどの経験があります。Git は、ユーザーのワークフローの選択に適合するように構築されたツールキットとは対照的に、概念に重きを置いた環境であるという点で GNU Arch と同じように感じられ、最初はかなり不快に感じました。］