マージエンジンが最も優れているリビジョンコントロールはどれですか。[閉まっている]

マージに関しては、各コントロールバージョンにそれを実行するエンジンがあります。競合は避けられませんが、問題は-どのリビジョン管理が競合を回避するのに最適なAIを持つかです。

そのようなものを測定することは可能ですか？

具体的には、GITへの移行を検討しています。これは、誇大宣伝とうわさがあり、競合をより適切に処理するためです...

コメントは大歓迎です...

これは正しい質問ではないと思います。

問題は、多くのコーナーケースがあり、マージ用の「スマート」アルゴリズムは、実際にコードを完全にスクローズしたときに、マージが正しく行われたと思い込ませることができることです。運が良ければ、そのような悪いマージはコンパイル時の失敗を引き起こします。運が悪いと、追跡に時間がかかる微妙なバグが発生する可能性があります。

Gitはかなり単純なマージアルゴリズムを使用し、手を上げて、マージできない場合は助けを求めます。私の意見では、これはまさにあなたがバージョン管理システムにしたいことです。これによって免れる悲しみの量は、競合を手動で修正するのにかかる時間に十分に値します。（また、マージで競合がある場合、gitは競合するファイルを自動生成されたコミットメッセージにリストします-これは、コード履歴を調べているときにエラーを見つけるのに非常に便利です）。

最良のアルゴリズムはDarcsのパッチ代数であると言われています。Codevilleにも興味深いアルゴリズムが開発されています。
ただし、すべての実用的な理由から、3者間マージを使用するツールであれば問題ありません。これにはgit（バリアントを含む）、mercurial、bazaar、および多くの外部ツール（注目に値する例外：Macのopendiffおよびkaleidoscope）が含まれるため、おそらく最良のオプションがすでに使用されています。@Peterが指摘したように、アルゴリズムが役に立たない場合があります。

私はgitとmercurialを使用していますが、あなたの質問はdarcsのパッチ理論を覚えています。今週末は宿題を読む予定です。

• http://en.wikipedia.org/wiki/Darcs
• http://byorgey.wordpress.com/2008/02/04/gobby-haskell-and-patch-theory/
• http://byorgey.wordpress.com/2008/02/07/patch-theory-thoughts-part-i/
• http://byorgey.wordpress.com/2008/02/13/patch-theory-part-ii-some-basics/

PD：パッチの理論を聞かないでください、私にとっては非常に複雑です:)

それはHuman Revision Controlと呼ばれていました。（Human Merging Engine）

私たちはSeapine Surroundを使用しており、ほとんどの場合、マージはうまく機能していますが、ソース管理で実行できないマージ競合を修正する唯一の方法は、人間の介入によるものです。

だから、私のアドバイスは：

すばやくマージしてみてください。悪夢の1つに、ほぼ2年間メインラインに復帰しないブランチがありました。それが統合されたとき、多くの衝突が解決される必要がありました。ある開発者は、マージの問題の修正に多くの時間を費やした後、「マージマスター」というニックネームを獲得しました。

ウィザードなどから自動生成されたコードに注意してください。同じファイルで2つのブランチが自動生成された変更を変更する場合、特にこれをマージするのが本当に面倒になることがあります。

開発を制御してみてください。開発者AがコードファイルXとYを分解している場合、開発者Bが別のブランチのXとYで作業することはあまり意味がありません。マージ管理の一部は、マージの競合の可能性を回避するために変更されているものを試行して制御することです。

これは、2人の開発者が2つの異なるブランチの同じファイルで作業することができないと言っているのではありません。1人の開発者がメソッドAを追加し、別の開発者がメソッドBを追加した場合、マージは簡単に行われるはずです。

結局のところ、常に人間の介入を必要とするいくつかの紛争があります。それらを最小限に抑えることにより、最良のマージ結果が得られます。

完璧なマージエンジンは、マージされるファイルのセマンティクスを理解します。つまり、ソースコードを解析して理解します。そのようなマージエンジン/バージョン管理はまだ見ていません...

ほとんどのマージツールは、ファイルをテキストとしてマージします。だから私は盲目的にそれらに依存することは決してありません、それをあなたのブランチにコミットする前に変更をレビューすることは常に良い考えです。

自動的にマージしないPerforceを使用しています。ソースファイルが共通ベースに関連して変更されるたびに、競合がない場合でもターゲットファイルを解決する必要があると表示されます。だから私はマージツールを開いて、それらが適切であるかどうかを確認するために考えたハンクをすばやくステップし（そして他のピアが何をしているかの大まかな画像を取得します）、ほとんどの場合、それらはフィットして結果を受け入れます。

また、メインラインの変更通知をサブスクライブしたので、ブランチへの変更をできるだけ早くマージして、後で問題を回避できるようにしています。

えっと...

mercurial（およびgitもそうだと思います）を使用する場合、マージエンジンを選択します。デフォルトではkdiff3ですが、（compare、p4mergeなどを除く）好きなものを使用できます。

多くの場合、マージエンジンとVCSは、コンパイラやテキストエディタのように、完全に独立しています。たとえば、XMLとコードを比較します。それらをマージするためにさまざまなものが必要になります。それらは同じように機能しないため、同じようにマージすることはできません。

より良いマージツールが必要なためにバージョン管理を切り替える場合、間違った理由でバージョン管理を切り替える必要があります。バージョン管理を切り替える必要があるのは、現在使用しているバージョンがプロセスにうまく適合しない場合（または別のプロセスが適切な場合）だけです。より良いプロセスを使用できるようにします）。

衝突は避けられない

VCSがファイル内の競合をどの程度適切に処理するかは、私の考えでは少し過大評価されています。まず、そのような紛争に対処する最善の方法は、そもそもそれらを持たないことです。ソフトウェアをうまく​​因数分解し、先見の明のある割り当てを分割することで、ファイルのクラスター内（ファイル内だけでなく）の競合を大幅に減らすことができます。あまりにも多くのgodクラスを投げたり、誰もが使用しなければならず、誰もがやりたがっている共通の構成ファイルを投げたり、ファイルレベルの競合を要求したりするなど、悪い仕事をしてください。

もう1つは、ほとんど同じ（お粗末な）アルゴリズムを使用していることです。例：私たちのプロジェクトのアルファ版リリースでマイナーなメモリリークが発生しました。これはリークというよりドリップであり、リークは初期化時間の終わりに停止しました。修正に値するものであり、パッチに値するものではありません。お客様の1人が問題を「修正」し、無料を間違った場所に置きました。この問題は次のリリースで修正されました。この顧客は、完全な置き換え（WTF？）ではなく、新しいリリースをマージしました。3者間マージで競合はありませんでした。freeへの呼び出しは、互いに分離されていました。そのため、ソフトウェアはダブルフリーのためにコアをドロップしています。

議論で見逃されているのは、作業をソフトウェアのメインラインにマージするのがどれほど難しい/時間のかかる/エラーが発生しやすいかです。

SVNでは、あなた

• 変更をブランチにコミットします。
• トランクをブランチにマージします。
• 大きなプロジェクトがある場合は、コーヒーブレークをとるか、ランチに行くことを考えてください。
• あなたが戻ってきたときに、あなたが木の衝突を見ることがないように祈ってください。
• マージの結果をブランチにコミットします。
• ブランチをトランクにマージします。
• 別のコーヒー休憩を取る。
• もう一度、戻ってきたときに木が衝突しないように祈ってください。
• 変更をトランクにコミットします。
• 同じことをしようとしていた同僚との衝突を避けるために、ドアを閉めてください。

これは非常に多くの非アトミックなステップであり、エラーが入り込む可能性のある場所が多すぎ（ツリーの競合は単に厄介なものです）、時間がかかりすぎます。マージプロセスが非常に時間がかかり、エラーが発生しやすいため、subversionでブランチを使用することをあきらめた複数のプロジェクトを見てきました。これにより、さらに多くのプロジェクトがsubversionから完全に切り替わるのを見てきました。

mergeと呼ばれる小さなテストスイートがあり、これはリビジョン管理システムを実際のマージシナリオと比較します。シナリオごとに、VCSが以下を正しく実行できることを確認します。

• 競合せずにブランチをマージする
• コンパイルするコードを生成する
• 正しく動作するコードを生成する

マージで成功したテストの数に基づくと、これには2つの層のパフォーマンスがあるようです。

1. Darcs、Git
2. Mercurialバザール

マージしようとしているプログラミング言語によっては、正確なテスト結果が重要になる場合があります。詳細な比較表については、プロジェクトのWebサイトを参照してください。

私はIBM / Rational ClearCaseを使用しており、マルチブランチのマージは素晴らしいです。subversionの周りにリングを実行します。（Gitや水銀の経験はありません。）