Git、Mercurial、Bazaarの相対的な長所と短所は何ですか？[閉まっている]

ここの人々は、Git、Mercurial、およびBazaarの相対的な長所と短所として何を理解していますか？

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

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

Gitは非常に高速で、拡張性が非常に高く、概念について非常に透過的です。これの欠点は、学習曲線が比較的急であることです。Win32ポートは利用可能ですが、一流の市民ではありません。Gitはハッシュをバージョン番号としてユーザーに公開します。これは保証を提供します（単一のハッシュは常にまったく同じコンテンツを参照します。攻撃者は検出されずに履歴を変更することはできません）が、ユーザーにとって煩わしい場合があります。Gitには、ファイルのコンテンツを追跡するという独自の概念があります。ファイルのコンテンツはファイル間を移動し、ファイルを第1レベルのオブジェクトとして表示しますが、ディレクトリは追跡しません。gitのもう1つの問題は、多くの操作（リベース）これにより、履歴の変更が簡単になります（ある意味で、ハッシュによって参照されるコンテンツは変更されませんが、そのハッシュへの参照は失われる可能性があります）。一部の純粋主義者（私も含む）は、それをあまり好きではありません。

Bazaarは適度に高速で（履歴が浅いツリーでは非常に高速ですが、現在は履歴の長さでスケーリングが不十分です）、従来のSCM（CVS、SVNなど）のコマンドラインインターフェースに精通している人には習得が容易です。Win32は、開発チームによって一流のターゲットと見なされています。さまざまなコンポーネント用のプラグ可能なアーキテクチャがあり、ストレージ形式を頻繁に置き換えます。これにより、新しい機能（異なる概念に基づくリビジョン管理システムとの統合に対するサポートの向上など）を導入し、パフォーマンスを向上させることができます。Bazaarチームは、ディレクトリトラッキングと名前変更のサポートを第一級の機能と見なしています。グローバルに一意のリビジョンID識別子はすべてのリビジョンで使用できますが、ツリーローカルrevno（標準リビジョン番号、リビジョンを識別するために、コンテンツハッシュの代わりにsvnまたは他の従来のSCMで使用されるものに類似しています。Bazaarは「軽量チェックアウト」をサポートしています。履歴はローカルシステムにコピーされるのではなくリモートサーバーに保持され、必要に応じてネットワーク経由で自動的に参照されます。現在、これはDSCM間でユニークです。

どちらも、SVN統合のいくつかの形式が利用可能です。ただし、bzr-svnは、主にその目的のために導入されたバックエンド形式の改訂により、git-svnよりもかなり優れています。[2014年の更新：サードパーティの商用製品SubGitは、SVNとGit間の双方向インターフェースを提供します。これは、忠実にbzr-svnに匹敵し、かなり洗練されています。予算とライセンスの制約が許す場合は、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を、埋め込みライブラリとして使用しています。私の雇用主の組織の他の部分はMercurialを多用しています。前の人生で、SVNを中心に多くの自動化を構築しました。それ以前は、GNU Arch、BitKeeper、CVSなどの経験があります。ユーザーのワークフローの選択に準拠するように構築されたツールキットとは対照的に、Gitは最初はかなり不快でした-コンセプトが重い環境である限り、GNU Archのように感じました-しかし、私はそれ以来、非常に慣れてきましたそれ]。

Ogre 3DプロジェクトのSteve Streetingがこのトピックに関するブログエントリを公開しました（2009年9月28日）。このトピックでは、Git、Mercurial、Bazaarの素晴らしく手利きの比較を行っています。。

結局、彼は3つすべての強みと弱みを見つけ、明確な勝者はありません。プラスの面では、彼はあなたがどちらに行くかを決めるのを助けるために素晴らしいテーブルを提供します。

その短い読みと私はそれを強くお勧めします。

ここの人々は、Git、Mercurial、およびBazaarの相対的な長所と短所として何を理解していますか？

私の意見では、Gitは、強みは、クリーンな基礎となるデザインと非常に豊富な機能のセットです。また、マルチブランチレポジトリやブランチを多用するワークフローの管理にも最適なサポートだと思います。非常に高速で、リポジトリサイズが小さい。

便利な機能がいくつかありますが、慣れるには少し手間がかかります。これらには、作業領域とリポジトリデータベースの間の目に見える中間ステージングara（インデックス）が含まれます。検出ある種のファイルIDを使用して追跡するのではなく、類似性ヒューリスティックを使用して名前変更とコピーをします。これは適切に機能し、ファイル全体のコードの移動を追跡し、大規模な名前変更だけでなく非難（注釈）を可能にします。

その欠点の1つは、MS Windowsのサポートが遅れており、完全ではないことです。別の認識されている不利な点は、たとえばMercurialほど文書化されておらず、競合ほどユーザーフレンドリーではありませんが、変化します。

私の意見ではMercurialは、強みは、優れたパフォーマンスと小さなリポジトリサイズ、優れたMS Windowsサポートにあります。

主な欠点は、私の意見では、ローカルブランチ（単一リポジトリ内の複数のブランチ）は依然として二流の市民であり、奇妙で複雑な方法でタグを実装しているという事実です。また、ファイル名の変更を処理する方法も最適ではありませんでした（ただし、この移行は変更されました）。Mercurialはタコのマージをサポートしていません（3つ以上の親との）。

私がBazaarの主な利点を聞いて読んだことから、中央集中型ワークフロー（これは不利な点であり、中央集中型の概念が表示されない場所に表示される）を簡単にサポートし、ファイルとディレクトリの両方の名前変更を追跡できます。

その主な欠点は、長い非線形履歴を持つ大規模リポジトリーのパフォーマンスとリポジトリー・サイズ（少なくとも大規模なリポジトリーではパフォーマンスが向上する）、デフォルトのパラダイムがリポジトリーごとに1つのランチであるという事実です（ただし、データを共有するように設定できます）。 、および一元化された概念（ただし、私が変更を聞いたことからも）。

GitはC、シェルスクリプト、Perlで記述されており、スクリプトに対応しています。MercurialはC（コア、パフォーマンス）とPythonで書かれており、拡張用のAPIを提供します。BazaarはPythonで書かれており、拡張用のAPIを提供します。

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

Subversion（SVN）、Perforce、ClearCaseなどのバージョン管理システムは、集中型のバージョン管理システムです。Git、Mercurial、Bazaar（およびDarcs、Monotone、BitKeeperも）は、分散バージョン管理システムです。分散バージョン管理システムにより、はるかに幅広いワークフローが可能になります。「準備ができたら公開」を使用できます。ブランチとマージ、およびブランチを多用するワークフローのサポートが向上しています。コミット権を持つ人を信頼して、簡単な方法で寄付を得る必要はありません。

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

検討する必要がある要素の1つは、SVNによる抽出のサポートです。Gitにはgit-svn、Bazaarにはbzr-svn、Mercurialにはhgsubversion拡張機能があります。

免責事項：私はGitユーザーであり、少しの時間の貢献者であり、gitメーリングリストを監視（および参加）しています。MercurialとBazaarは、ドキュメント、IRCとメーリングリストに関するさまざまなディスカッション、およびさまざまなバージョン管理システムを比較するブログの投稿と記事（Git WikiのGitComparisonページにリストされているものもある）からのみ知っています。

InfoQには良い比較があります。

MercurialとBazaarは、表面上は非常に似ています。どちらも、オフラインコミットや複数のブランチのマージと同様に、基本的な分散バージョンコントロールを提供します。どちらもPythonで記述されており、どちらもgitより低速です。コードを掘り下げると多くの違いがありますが、Mercurialの方がやや勢いがあるように見えますが、日常の日常業務ではそれらは事実上同じです。

Gitは初心者向けではありません。MercurialとBazaarの両方よりもはるかに高速で、Linuxカーネルを管理するために作成されました。これは3つの中で最速であり、かなりの差で3つの中で最も強力です。Gitのログおよびコミット操作ツールは他に類を見ません。ただし、これは最も複雑で、使用するのが最も危険です。特にgitの内部動作を理解していない場合は、コミットを失ったり、リポジトリを台無しにしたりするのは非常に簡単です。

最近Python開発者が行った比較を見てください：http : //wiki.python.org/moin/DvcsComparison。彼らは、3つの重要な理由に基づいてMercurialを選択しました。

Mercurialを選択したのは、3つの重要な理由によります。

• 小規模な調査によると、Python開発者はBazaarやGitよりもMercurialの使用に関心があります。
• MercurialはPythonで書かれており、python-devが「自分のドッグフードを食べる」傾向に一致しています。
• Mercurialはbzrよりも大幅に高速です（差ははるかに小さいものの、gitよりも低速です）。
• Mercurialは、BazaarよりもSVNユーザーにとって習得が容易です。

（http://www.python.org/dev/peps/pep-0374/から）

Sunは、SolarisコードベースのSun Teamware VCSを置き換える候補として、git、Mercurial、およびBazaarの評価を行いました。とても面白かったです。

バザーで欠けている非常に重要なことはcpです。SVNのように、同じ履歴を共有する複数のファイルを持つことはできません。たとえば、こことここを参照してください。cpを使用する予定がない場合は、bzrがsvnの優れた（そして非常に使いやすい）代替品です。

私はしばらくの間バザールを使用していましたが、とても気に入りましたが、それは小規模なプロジェクトでしかなく、それでもかなり遅くなりました。とても簡単に習得できますが、それほど速くはありません。ただし、これは非常にXプラットフォームです。

現在使用しているGitは、バージョン1.6以降、使用するコマンドに関して他のVCSと非常に似ているため、とても気に入っています。

DVCSの使用における私の経験の主な違いはこれだと思います：

1. Gitには最も活気のあるコミュニティがあり、Gitに関する記事を見るのが一般的です
2. GitHubは本当に素晴らしいです。Launchpad.netは問題ありませんが、Githubの喜びに勝るものはありません
3. Gitのワークフローツールの数はすばらしいものです。あらゆる場所に統合されています。Bzrにはいくつかありますが、それほど多くはありません。

要約すると、BVCはDVCSで歯を切るときに素晴らしかったですが、今ではGitとGithubにとても満足しています。

これは、これらの小さなテキストボックスの1つに入力するのに長い時間がかかるコンテキストに大きく依存する大きな質問です。また、これらの3つすべては、ほとんどのプログラマーが行う通常のものに使用した場合、実質的に類似しているように見えるため、違いを理解することにもかなり難解な知識が必要です。

これらのツールの分析を、より具体的な質問があるポイントに分解できれば、おそらくはるかに良い答えが得られます。

BazaarはgitよりもIMHOの方が習得が容易です。Gitはgithub.comで優れたサポートを提供しています。

両方を使って、どちらがあなたに一番合っているか決めるのがいいと思います。

ここの人々は、Git、Mercurial、およびBazaarの相対的な長所と短所として何を理解していますか？

これは非常にオープンな質問であり、フレームベイトに接しています。

Gitが最も高速ですが、3つすべてが十分に高速です。Bazaarは最も柔軟で（SVNリポジトリに対して透過的な読み取り/書き込みサポートを備えています）、ユーザーエクスペリエンスを重視しています。Mercurialは途中のどこかにあります。

3つのシステムすべてにファンがたくさんいます。私は個人的にバザールのファンです。

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

前者は分散システムです。後者は集中型システムです。さらに、Perforceは独自仕様であり、他のすべてはスピーチのように無料ですです。

集中型と分散型のどちらを選択するかは、そのカテゴリ内で言及したどのシステムよりもはるかに重要です。

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

まず、TortoiseSVNに代わる優れた機能がありません。Bazaarは独自のTortoiseバリアントに取り組んでいますが、2008年9月の時点ではまだありません。

次に、分散システムの使用が彼らの仕事にどのように影響するかについて、主要な人々を訓練する。

最後に、課題追跡、夜間ビルドシステム、自動テストシステムなど、システムの残りの部分との統合。

あなたの主要な問題は、これらが分散 SCMであり、そのためユーザーの考え方に少し変更が必要になることです。人々がアイデアに慣れると、技術的な詳細と使用パターンが適切になりますが、特に企業の環境では、その最初のハードルを過小評価しないでください。すべての問題は人の問題です。

ddaa.myopenid.comはそれについて言及しましたが、再度言及する価値があると思います。BazaarはリモートSVNリポジトリに対して読み取りと書き込みを行うことができます。つまり、チームの他のメンバーがまだSubversionを使用している間に、ローカルでBazaarを概念実証として使用できます。

編集：ほとんどすべてのツールにSVNとやり取りする方法がいくつかありますが、私は非常にうまくgit svn機能する個人的な経験を持っています。私はそれを何ヶ月も使用しており、しゃっくりを最小限に抑えています。

Linus Torvaldsによるgitの良いビデオがあります。彼はGitの作成者なので、これは彼が宣伝するものですが、ビデオでは、分散SCMとは何か、なぜ集中型SCMより優れているのかを説明しています。git（mercurialは問題ないと見なされます）とcvs / svn / perforceを比較することにはかなりの数があります。分散SCMへの移行に関して、聴衆からの質問もあります。

私はこの資料が啓発的であるとわかり、分散SCMに販売されました。しかし、Linusの努力にもかかわらず、私の選択は水銀です。理由はbitbucket.orgです。githubよりも（寛大に）優れていることがわかりました。

ここで、一言注意が必要です。Linusはかなりアグレッシブなスタイルです。彼は面白くなりたいと思っていますが、笑いませんでした。それとは別に、分散SCMに慣れておらず、SVNからの移行を検討している場合、ビデオは素晴らしいものです。

http://www.youtube.com/watch?v=4XpnKHJAok8

分散バージョン管理システム（DVCS）は、集中型VCSとは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。

集中化されたVCSシステムは、祝福された、したがって良い1つの真のソースがあるという意図で設計されています。すべての開発者はそのソースから作業（チェックアウト）し、次に変更を追加（コミット）します。変更は同様に祝福されます。CVS、Subversion、ClearCase、Perforce、VisualSourceSafe、およびその他すべてのCVCSの唯一の本当の違いは、各製品が提供するワークフロー、パフォーマンス、統合にあります。

分散型VCSシステムは、1つのリポジトリが他のリポジトリと同じように機能するように設計されており、1つのリポジトリから別のリポジトリへのマージは、もう1つの通信形式です。どのリポジトリを信頼すべきかについての意味論的価値は、ソフトウェア自体ではなく、プロセスによって外部から課せられます。

どちらのタイプを使用するかという本当の選択は組織的です-プロジェクトまたは組織が集中管理を必要とする場合、DVCSは重要ではありません。中央リポジトリへの安全なブロードバンド接続なしで、開発者が国や世界中で作業することが期待される場合、DVCSがおそらく救いです。両方が必要な場合は、fsckです。