Git、Mercurial、およびBazaarの相対的な長所と短所は何ですか？
ここの人々は、Git、Mercurial、およびBazaarの相対的な長所と短所として何を見ていますか？
それぞれを相互に検討し、SVNやPerforceなどのバージョン管理システムに対して検討する場合、どのような問題を考慮する必要がありますか？
SVNからこれらの分散バージョン管理システムの1つへの移行を計画する際に、どのような要因を考慮しますか？
Gitは非常に高速で、非常に優れた拡張性を備えており、その概念について非常に透過的です。この欠点は、比較的急な学習曲線を持つことです。 Win32ポートは利用可能ですが、一流の市民ではありません。 Gitはハッシュをバージョン番号としてユーザーに公開します。これは保証を提供します（単一のハッシュは常にまったく同じコンテンツを参照するため、攻撃者は検出されずに履歴を変更することはできません）が、ユーザーにとって面倒です。 Gitにはファイルのコンテンツを追跡するという独自の概念があり、それらのコンテンツはファイル間を移動し、ファイルを第1レベルのオブジェクトとして表示しますが、ディレクトリは追跡しません。 gitのもう1つの問題は、多くの操作（たとえば リベース）履歴を簡単に変更できるようにします（ある意味、ハッシュによって参照されるコンテンツは変更されませんが、そのハッシュへの参照は失われる可能性があります）。一部の純粋主義者（私自身も含む）は、あまり好きではありません。
Bazaarは適度に高速で（浅い履歴を持つツリーでは非常に高速ですが、現在は履歴の長さに応じてスケーリングが不十分です）、従来のSCM（CVS、SVNなど）のコマンドラインインターフェイスに精通している人には簡単に学習できます。 Win32は、開発チームによって一流のターゲットと見なされています。さまざまなコンポーネント用のプラグ可能なアーキテクチャを備えており、そのストレージ形式を頻繁に置き換えます。これにより、新しい機能（さまざまな概念に基づいたリビジョン管理システムとの統合のサポートの改善など）を導入し、パフォーマンスを向上させることができます。 Bazaarチームは、ディレクトリトラッキングと名前変更のサポートを第一級の機能と見なしています。グローバルに一意のリビジョンID識別子はすべてのリビジョンで使用可能ですが、ツリーローカルrevnos（標準リビジョン番号、svnまたは他の従来のSCMで使用されるものに類似）は、リビジョンを識別するためのコンテンツハッシュの代わりに使用されます。 Bazaarは「軽量チェックアウト」をサポートしています。このシステムでは、履歴はローカルシステムにコピーされる代わりにリモートサーバーに保持され、必要に応じてネットワーク経由で自動的に参照されます。現在、これはDSCMの中でユニークです。
両方とも何らかの形式のSVN統合が利用可能です。ただし、bzr-svnはgit-svnよりもかなり優れています。これは主に、その目的のために導入されたバックエンド形式の改訂が原因です。 [2014年現在の更新：サードパーティの商用製品SubGitは、bzr-svnに忠実で、かなり洗練されたSVNとGit間の双方向インターフェースを提供します。私 強く 予算とライセンスの制約が許す場合は、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の強さは、その基礎となるクリーンなデザインと非常に豊富な機能セットです。また、マルチブランチリポジトリとブランチの重いワークフローの管理に対する最適なサポートがあると思います。これは非常に高速で、リポジトリサイズが小さくなっています。
便利な機能がいくつかありますが、慣れるには多少の労力が必要です。これらには、作業領域とリポジトリデータベース間のvisible中間ステージングara（インデックス）が含まれます。これにより、より複雑なケースでのマージ解決、インクリメンタルコミット、ダーティツリーでのコミットが可能になります。 検出何らかの種類のファイルIDを使用して追跡するのではなく、類似性ヒューリスティックを使用して名前変更とコピーを検出します。これはうまく機能し、ファイル間のコード移動を追跡できる非難（注釈）を可能にします大規模な名前の変更だけではありません。
その欠点の1つは、MS Windowsサポートが遅れており、完全ではないことです。もう1つの不利な点は、たとえばMercurialほど文書化されておらず、競合他社ほどユーザーフレンドリーではないが、変化することです。
私の意見ではMercurialの強みは、その優れたパフォーマンスと小さなリポジトリサイズ、そしてその優れたMS Windowsサポートにあります。
主な欠点は、ローカルブランチ（単一のリポジトリ内の複数のブランチ）が依然として二流市民であり、奇妙で複雑な方法でタグを実装するという事実です。また、ファイルの名前変更の処理方法は最適ではありませんでした（ただし、この移行は変更されました）。 Mercurialは、タコのマージをサポートしていません（3つ以上の親を持つ）。
私が聞いて読んだ主なBazaarの利点は、集中化されたワークフローを簡単にサポートできることです（これは、集中化された概念が表示されるべきではないという欠点もあります） ）、ファイルとディレクトリの両方の名前の変更を追跡します。
その主な欠点は、長い非線形履歴を持つ大きなリポジトリのパフォーマンスとリポジトリサイズ（少なくともあまり大きくないリポジトリのパフォーマンスが向上する）、デフォルトのパラダイムがリポジトリごとに1つの牧場であるという事実です（ただし、データを共有するように設定できます） 、および集中化された概念（ただし、それは私が聞いたことからも変わります）。
GitはC、シェルスクリプト、およびPerlで記述されており、スクリプト化可能です。 MercurialはC（コア、パフォーマンス用）およびPythonで記述され、拡張用のAPIを提供します。 BazaarはPythonで書かれており、拡張機能のAPIを提供します。
SVNやPerforceなどのバージョン管理システムに対して、それぞれを検討する際に、どのような問題を考慮する必要がありますか？
Subversion（SVN）、Perforce、ClearCaseなどのバージョン管理システムは、centralizedバージョン管理システムです。 Git、Mercurial、Bazaar（およびDarcs、Monotone、BitKeeper）は分散型バージョン管理システムです。分散バージョン管理システムにより、はるかに広範なワークフローが可能になります。 「準備ができたら公開」を使用できます。分岐とマージ、および分岐が多いワークフローのサポートが向上しています。コミットアクセスを持つ人々を信頼して、簡単な方法で貢献を得る必要はありません。
SVNからこれらの分散バージョン管理システムの1つへの移行を計画する際、どのような要素を考慮しますか？
考慮すべき要因の1つは、SVNでの不等化のサポートです。 Gitにはgit-svn、Bazaarにはbzr-svn、Mercurialにはhgsubversion拡張機能があります。
免責事項：私はGitユーザーであり、少人数の貢献者であり、gitメーリングリストを監視（および参加）しています。 MercurialとBazaarは、ドキュメント、IRCとメーリングリストに関するさまざまな議論、およびさまざまなバージョン管理システムを比較するブログ投稿と記事（一部は GitComparison Git Wikiのページ）。
InfoQには a nice comparison があります。
MercurialとBazaarは、表面上は非常に似ています。どちらも、オフラインコミットや複数のブランチのマージなど、基本的な分散バージョン管理を提供します。両方ともpythonで記述されており、どちらもgitよりも低速です。コードを詳しく調べると、多くの違いがあります、日常の日常業務では、Mercurialにはもう少し勢いがあるように見えますが、実質的に同じです。
Gitは、初心者向けではありません。 MercurialとBazaarの両方よりもはるかに高速で、Linuxカーネルを管理するために作成されました。これは3つの中で最速であり、3つの中で最も強力でもあり、かなりマージンがあります。 Gitのログおよびコミット操作ツールは他に類を見ません。ただし、これは最も複雑で使用するのが最も危険です。特にgitの内部動作を理解していない場合は、コミットを失ったり、リポジトリを破壊したりするのは非常に簡単です。
Python開発者： http://wiki.python.org/moin/DvcsComparison によって最近行われた比較をご覧ください。理由：
Mercurialを選択した理由は、次の3つの重要な理由からです。
- 小規模な調査によると、Python開発者は、BazaarやGitよりもMercurialの使用に関心があります。
- MercurialはPythonで書かれており、これはpython-devが「自分のドッグフードを食べる」傾向に一致しています。
- Mercurialはbzrよりも大幅に高速です（gitよりも遅いですが、違いははるかに小さいです）。
- Mercurialは、SVNユーザーにとってBazaarよりも簡単に学習できます。
私はしばらくの間Bazaarを使用していましたが、それはとても好きでしたが、それは小さなプロジェクトでしかなく、それでもかなり遅かったです。とても簡単に学べますが、超高速ではありません。ただし、非常にxプラットフォームです。
現在、バージョン1.6で使用するコマンドの点で他のVCSとはるかに似ているため、非常に気に入っているGitを使用しています。
DVCSの使用に関する私の経験の主な違いは次のとおりです。
- Gitには最も活気のあるコミュニティがあり、Gitに関する記事を見るのが一般的です
- GitHub 本当に素晴らしい。 Launchpad.netは大丈夫ですが、Githubの喜びに勝るものはありません
- Gitのワークフローツールの数は非常に多くなっています。至る所で統合されています。 Bzrにはいくつかありますが、それほど多くはありません。
要約すると、DVCSで歯を切っていたときにBzrは素晴らしかったが、今ではGitとGithubに非常に満足しています。
あなたの主な問題は、これらがDistributed SCMであり、そのため、ユーザーの考え方に少し変更を加える必要があることです。人々がアイデアに慣れると、技術的な詳細と使用パターンが適切になりますが、特に企業環境では、最初のハードルを過小評価しないでください。すべての問題は人の問題です。
Bazaarはgitよりも簡単に学ぶことができます。 Gitはgithub.comでNiceをサポートしています。
両方を使用して、どちらが最も適しているかを判断する必要があると思います。
これは、これらの小さなテキストボックスのいずれかに入力するのに多くの時間を要するコンテキストに大きく依存する大きな質問です。また、これらの3つはすべて、ほとんどのプログラマーが行う通常の作業に使用すると実質的に類似しているように見えるので、違いを理解するためにもかなり難解な知識が必要です。
これらのツールの分析を、より具体的な質問がある時点まで分解できれば、おそらくより良い答えが得られます。
ここの人々は、Git、Mercurial、およびBazaarの相対的な長所と短所として何を見ていますか？
これは非常に未解決の質問であり、フレームベイトに隣接しています。
Gitは最速ですが、3つとも十分に高速です。 Bazaarは最も柔軟で（SVNリポジトリーに対する透過的な読み取り/書き込みサポートがあります）、ユーザーエクスペリエンスを重視します。 Mercurialは中間のどこかにあります。
3つのシステムすべてに多くのファンボーイがいます。私は個人的にバザーのファンです。
それぞれを相互に検討し、SVNやPerforceなどのバージョン管理システムに対して検討する場合、どのような問題を考慮する必要がありますか？
前者は分散システムです。後者は集中型システムです。さらに、Perforceは独自仕様ですが、他のすべては無料です スピーチのように 。
集中型と分散型は、そのカテゴリ内で言及したどのシステムよりもはるかに重要な選択です。
SVNからこれらの分散バージョン管理システムの1つへの移行を計画する際に、どのような要因を考慮しますか？
まず、TortoiseSVNに代わる適切なツールがないこと。 Bazaarは独自に Tortoise variant で作業していますが、2008年9月の時点ではまだありません。
次に、主要な人々に、分散システムの使用が仕事にどのように影響するかについてトレーニングします。
最後に、課題追跡システム、夜間ビルドシステム、自動テストシステムなど、システムの他の部分との統合。
ddaa.myopenid.comがついに言及しましたが、もう一度言及する価値があると思います。BazaarはリモートSVNリポジトリを読み書きできます。つまり、チームの他のメンバーがまだSubversionを使用している間に、Bazaarを概念実証としてローカルで使用できるということです。
編集：ほとんどすべてのツールにsomeSVNと対話する方法がありますが、git svn動作極端によく。しゃっくりを最小限に抑えながら、何ヶ月も使用しています。
Linus Torvaldsによるgitの良いビデオがあります。彼はGitの作成者であるため、これは彼が推進するものですが、ビデオでは分散型SCMとは何か、なぜ集中型SCMよりも優れているのかを説明しています。 git（MercurialはOKと見なされます）とcvs/svn/perforceを比較することはかなりあります。分散SCMへの移行に関して、聴衆からの質問もあります。
この資料が啓発的であることがわかり、分散型SCMに売却されました。しかし、Linusの努力にもかかわらず、私の選択はMercurialです。理由はbitbucket.orgで、githubよりも優れている（より寛大な）ことがわかりました。
私はここで警告の言葉を言う必要があります。リーナスは非常に攻撃的なスタイルを持っています。それとは別に、分散SCMを初めて使用し、SVNからの移行を検討する場合、ビデオは素晴らしいです。
分散バージョン管理システム（DVCS）は、集中型VCSとは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。
集中型VCS システムは、1つの真のソースが祝福され、それゆえに良いという意図を持って設計されています。すべての開発者はそのソースから作業（チェックアウト）し、変更を追加（コミット）します。変更は同様に祝福されます。 CVS、Subversion、ClearCase、Perforce、VisualSourceSafe、および他のすべてのCVCSの唯一の本当の違いは、各製品が提供するワークフロー、パフォーマンス、統合にあります。
Distributed VCS システムは、あるリポジトリが他のリポジトリと同等であり、あるリポジトリから別のリポジトリにマージすることは、別の通信形態であるという意図で設計されています。どのリポジトリを信頼するかについてのセマンティック値は、ソフトウェア自体ではなく、プロセスによって外部から課せられます。
どちらのタイプを使用するかという実際の選択は組織です。プロジェクトまたは組織が集中管理を必要とする場合、DVCSはスターターではありません。開発者が、中央リポジトリへの安全なブロードバンド接続なしで、国/世界中で働くことが期待される場合、DVCSがおそらく救いです。両方が必要な場合は、fsck'dです。