ここにいる人々は、Git、Mercurial、Bazaar の相対的な長所と短所をどのように見ていますか?
SVN や Perforce などのバージョン管理システムに対して、それぞれを検討する際に、どのような問題を考慮する必要がありますか?
SVN からこれらの分散型バージョン管理システムの 1 つへの移行を計画する際、どのような要素を考慮しますか?
17445 次
15 に答える
147
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 (ダルクも含む) よりも大幅に低く、履歴の長さやファイル数のいずれかの点で大きくなりがちなプロジェクトでは避ける必要があります。
[著者について: 仕事では Git と Perforce を使用し、個人的なプロジェクトと組み込みライブラリとして Bazaar を使用しています。私の雇用主の組織の他の部分では、Mercurial を頻繁に使用しています。前世では、SVN を中心に多くの自動化を構築しました。それ以前は、GNU Arch、BitKeeper、CVS などの経験があります。Git は最初は非常に不快でした -- ユーザーのワークフローの選択に適合するように構築されたツールキットとは対照的に、概念が重たい環境であるという点で、GNU Arch のように感じました -- しかし、私はそれ以来、非常に快適に使用できるようになりましたそれ]。
于 2008-09-16T22:05:28.603 に答える
19
Ogre 3D プロジェクトの Steve Streeting はちょうど (2009 年 9 月 28 日)、このトピックに関するブログ エントリを公開しました。彼は、Git、Mercurial、および Bazaar の優れた比較を行っています。
最終的に、彼は 3 つすべてで長所と短所を見つけ、明確な勝者は見つけません。プラス面として、彼はあなたがどちらを選ぶかを決めるのに役立つ素晴らしいテーブルを提供します.
短い読み物で、強くお勧めします。
于 2009-09-28T19:52:16.497 に答える
8
MercurialとBazaarは、表面的には非常によく似ています。オフラインコミットや複数のブランチのマージのように、どちらも基本的な分散バージョン管理を提供し、どちらもPythonで記述されており、どちらもgitよりも低速です。コードを掘り下げると多くの違いがありますが、Mercurialにはもう少し勢いがあるように見えますが、日常のタスクでは、それらは事実上同じです。
Gitは、初心者向けではありません。MercurialとBazaarの両方よりもはるかに高速で、Linuxカーネルを管理するために作成されました。これは3つの中で最速であり、3つの中で最も強力でもあります。Gitのログおよびコミット操作ツールは比類のないものです。ただし、使用するのも最も複雑で最も危険です。特にgitの内部動作を理解していない場合は、コミットを失ったり、リポジトリを台無しにしたりするのは非常に簡単です。
于 2008-09-16T22:11:09.963 に答える
7
Python 開発者によって最近行われた比較を見てみましょう: http://wiki.python.org/moin/DvcsComparison。彼らは次の 3 つの重要な理由に基づいて Mercurial を選択しました。
Mercurial を選択したのには、次の 3 つの重要な理由があります。
- 小規模な調査によると、Python 開発者は Bazaar や Git よりも Mercurial の使用に関心があります。
- Mercurial は Python で書かれており、これは「独自のドッグフードを食べる」という python-dev の傾向と一致しています。
- Mercurial は bzr よりも大幅に高速です (差ははるかに小さいですが、git よりは低速です)。
- Mercurial は、SVN ユーザーにとって Bazaar よりも習得が容易です。
于 2009-05-22T13:30:42.070 に答える
5
Sun は、Solaris コード ベース用の Sun Teamware VCS を置き換える候補として、 git、Mercurial、およびBazaarの評価を行いました。とても興味深いと思いました。
于 2008-09-17T03:13:55.913 に答える
2
私はしばらくの間Bazaarを使用していましたが、それは私がとても気に入っていましたが、それは小さなプロジェクトにすぎず、それでもかなり遅いものでした。学ぶのはとても簡単ですが、超高速ではありません。ただし、これは非常にxプラットフォームです。
私は現在、バージョン1.6で使用するコマンドの点で他のVCSに非常に似ているため、非常に気に入っているGitを使用しています。
DVCSの使用経験の主な違いは、次のとおりです。
- Gitには最も活気のあるコミュニティがあり、Gitに関する記事を見るのが一般的です。
- GitHubは本当に素晴らしいです。Launchpad.netは大丈夫ですが、Githubの喜びのようなものはありません
- Gitのワークフローツールの数は非常に多いです。それは至る所で統合されています。Bzrにはいくつかありますが、それほど多くはなく、維持もされていません。
要約すると、DVCSで歯を切っていたとき、Bzrは素晴らしかったですが、今ではGitとGithubに非常に満足しています。
于 2009-01-29T20:24:03.060 に答える
1
Bazaar は git よりも簡単に習得できます。Git は github.com で適切にサポートされています。
両方使ってみて、どちらが自分に合っているか決めればいいと思います。
于 2008-09-16T22:20:56.053 に答える
1
ここにいる人々は、Git、Mercurial、および Bazaar の相対的な長所と短所をどのように見ていますか?
これは非常にオープンな質問で、炎の餌に隣接しています。
Git が最速ですが、3 つとも十分に高速です。Bazaar は最も柔軟性があり (SVN リポジトリの透過的な読み書きをサポートしています)、ユーザー エクスペリエンスを重視しています。Mercurial はその中間です。
3 つのシステムにはすべて、ファンボーイがたくさんいます。私は個人的にバザーのファンです。
SVN や Perforce などのバージョン管理システムに対して、それぞれを検討する際に、どのような問題を考慮する必要がありますか?
前者は分散システムです。後者は集中型システムです。さらに、Perforce はプロプライエタリですが、他のすべてはスピーチのように自由です。
集中型か分散型かは、あなたがそのカテゴリーで言及したどのシステムよりも重要な選択です。
SVN からこれらの分散型バージョン管理システムの 1 つへの移行を計画する際、どのような要素を考慮しますか?
まず、TortoiseSVN の適切な代替手段がありません。Bazaar は独自のTortoise バリアントに取り組んでいますが、2008 年 9 月の時点ではまだありません。
次に、分散型システムの使用が彼らの仕事にどのように影響するかについて主要な人々を訓練します。
最後に、課題トラッカー、ナイトリー ビルド システム、自動テスト システムなどの残りのシステムとの統合。
于 2008-09-16T22:29:24.380 に答える
1
git には、Linus Torvalds による優れたビデオがあります。彼は Git の作成者であり、Git を推進していますが、ビデオでは、分散 SCM とは何か、なぜ集中型 SCM よりも優れているのかを説明しています。git (mercurial は問題ないと見なされます) と cvs/svn/perforce を比較することはかなりあります。分散 SCM への移行に関する聴衆からの質問もあります。
この資料は啓発的であることがわかり、私は分散型 SCM に売り込まれました。しかし、Linus の努力にもかかわらず、私の選択は気まぐれです。その理由は bitbucket.org にあります。github よりも優れている (より寛大な) ことがわかりました。
私はここで警告の言葉を言う必要があります.Linusはかなり攻撃的なスタイルを持っています.私は彼が面白くなりたいと思っていると思います. それとは別に、分散 SCM を初めて使用し、SVN からの移行を検討している場合、このビデオは素晴らしいものです。
于 2009-04-23T22:19:27.590 に答える
1
あなたの主な問題は、これらが分散型SCM であるため、ユーザーの考え方を少し変える必要があるということです。人々がアイデアに慣れると、技術的な詳細と使用パターンが適切に理解されますが、特に企業環境では、その最初のハードルを過小評価しないでください. すべての問題は人の問題であることを忘れないでください。
于 2008-09-18T10:17:20.737 に答える
1
ddaa.myopenid.com がついでに言及しましたが、もう一度言及する価値があると思います: Bazaar はリモートの SVN リポジトリを読み書きできます。つまり、チームの他のメンバーがまだ Subversion を使用している間に、ローカルで Bazaar を概念実証として使用できるということです。
編集: ほぼすべてのツールが SVN と対話する方法を備えていますが、個人的な経験でgit svnは非常にうまく機能しています。私はしゃっくりを最小限に抑えて、何ヶ月もそれを使用してきました.
于 2008-09-17T09:50:42.107 に答える
1
これはコンテキストに大きく依存する大きな質問であり、これらの小さなテキスト ボックスの 1 つに入力するのに多くの時間がかかります。また、これら 3 つすべては、ほとんどのプログラマーが行う通常の作業に使用すると実質的に類似しているように見えるため、違いを理解するだけでもかなり難解な知識が必要です。
これらのツールの分析を、より具体的な質問が得られるポイントまで分解できれば、おそらくより良い答えが得られるでしょう。
于 2008-09-16T21:57:40.383 に答える
0
分散バージョン管理システム（DVCS）は、集中型VCSとは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。
一元化されたVCSシステムは、祝福された、したがって優れた1つの真のソースが存在することを意図して設計されています。すべての開発者はそのソースから作業（チェックアウト）し、変更を追加（コミット）します。変更は同様に祝福されます。CVS、Subversion、ClearCase、Perforce、VisualSourceSafeと他のすべてのCVCSの唯一の本当の違いは、各製品が提供するワークフロー、パフォーマンス、および統合にあります。
分散VCSシステムは、あるリポジトリが他のリポジトリと同じように優れていることを意図して設計されており、あるリポジトリから別のリポジトリにマージすることは、単なる別の形式の通信です。どのリポジトリを信頼すべきかに関するセマンティック値は、ソフトウェア自体ではなく、プロセスによって外部から課されます。
どちらのタイプを使用するかを実際に選択するのは組織です。プロジェクトまたは組織が集中管理を必要とする場合、DVCSは初心者ではありません。開発者が中央リポジトリへの安全なブロードバンド接続なしで国/世界中で働くことが期待される場合、DVCSはおそらくあなたの救いです。両方が必要な場合は、fsckを実行します。
于 2008-09-16T22:15:41.730 に答える