問題タブ [three-way-merge]

私はTortoiseSVN、svn、subclipseを使用していて、基本は理解していると思いますが、しばらくの間私を悩ませてきたことが1つあります。それは、マージによって不要なコードが導入されることです。手順は次のとおりです。

trunk/test.txt@r2。テストファイルは「A」とリターンで作成されました：

branches/TRY-XX-Foo/test.txt@r3。に分岐しましtrunkたTRY-XX-Foo：

branches/TRY-XX-Foo/test.txt@r4。に不要な変更を加えTRY-XX-Fooてコミットしました：

branches/TRY-XX-Foo/test.txt@r5。重要なバグ修正をTRY-XX-Foo行い、それをコミットしました：

ここで、重要なバグ修正のみをトランクにマージしたいと思います。だから、私はリビジョンのためにマージを実行し4:5ます。作業ディレクトリにたどり着くのは競合です。

trunk/test.txt：

私の意志に反して、Subversionはトランクコードに「不要な変更」を含めたので、手動でそれらを取り除く必要があります。ブランチで複数の連続した変更が行われたときに、指定されたリビジョンのみをマージする方法はありますか？

問題の一部は、B（不要な変更）が.merge-rightに含まれていて、それがどのリビジョンからのものであるかを区別できないことです。私は通常TortoiseMergeを使用しますが、次のようになります。

私は現在、RCS のマージ コマンドを使用して 3 方向のマージを行っていますが、常に 1 つの問題に悩まされていました。-A オプションを使用すると、両方のファイルで行われた同じ変更が競合として表示されます。

<<<<<<< file1
file1 行 1
||||||| orig
orig line 1
======= file2
line 1
>>>>>>> file2
orig line 2
<<<<<<< orig =======
両方
の変更で追加された行
>>>>> >> file2
元の行 3

デフォルト (-E) を使用すると、これらの同一の変更は表示されませんが、出力には、祖先ではなく、次のような 2 つのコントリビューターのみが表示されます。

<<<<<<< file1
file1 line 1
=======
file2 line 1
>>>>>>> file2
orig line 2
行を両方の変更で追加
orig line 3

基本的に RCS マージと同じ動作をするが、同一の変更を自動的にマージしながら、競合する 3 つのバージョンすべてを表示する何らかの方法を持つプログラムはありますか?

BC3 を Subversion の差分ツールとして機能させる方法を説明したこの投稿を見ましたが、Beyond Compare 3 を使用して 3 方向のマージ/比較を行うにはどうすればよいでしょうか?

JavaScriptまたはPHPでのオープンソースの3者間マージの実装を知っている人はいますか？サーバー側のバイナリに依存せずにプレーンテキストファイルをマージしたい。

差分を作成するためのいくつかの解決策を見つけましたが、マージの実装はありませんでした。

UltraCompare Proは最初にリリースされてからユーザーであり、非常にフル機能の比較およびマージツールだと思います。ただし、DVCSを詳しく調べているので、DVCSは、他のツール（ほとんど？）とは異なる方法で3方向マージを処理することがわかりました。それで、それがなぜなのか、そしてそれが原因で何かが足りないのではないかと思います。

UltraCompareには、3つのマージパネルがあります（ベース、ローカル、その他と呼びましょう）。すべてのマージアクションは、これらのパネル内で行われます。実際には、これは、中央のペイン（ローカル）で作業を行い、右側（その他）または左側（ベース）の共通の祖先からの変更をマージすることを意味します。中央のペインはセッション中に変更されてから保存され、マージの結果としてコミットされます。4番目のペイン（出力ウィンドウ）には、差分結果に関する情報のみが含まれています。

_{（出典：ultraedit.com）}

他のツールでは、3つのペインは読み取り専用の状態でのみ存在し、4番目の下部のペイン（出力）はすべてのマージが行われる場所であるように見えます。追加のマージウィンドウを使用する理由は何ですか？すべての変更を追跡する方が簡単ですか？それとも、誰もが常にこのようにやっているので、その動作をコピーしているのでしょうか？これについてどう思いますか？

_{（ソース：hginit.com）}

最良の答えがあるのか​​正しい答えがあるのか​​わからないので、まだこの質問をCWにしませんが、ここでもあなたの意見を尊重します。

何千ものファイルと、同じディレクトリに適用される 2 つのパッチ ファイルを含むディレクトリがあります。各パッチ ファイルは、ディレクトリまたはそのサブディレクトリにある 20 ～ 30 個のファイルにパッチを適用します。

いずれかのパッチを共通の祖先ディレクトリに適用すると、成功します。

しかし、1 つのパッチ ファイルを適用した後に別のパッチ ファイルを適用すると、1 つのパッチ ファイルが適用された後に行番号が変更されるため、失敗します。(両方のパッチ ファイルは、共通の祖先からの差分を格納します)。また、一部の場所では、meld などのグラフィカル ツールを使用して 3 方向マージを行いたいという競合があります。

私の目標は、パッチ ファイルから 3 方向のマージを実行し、この最終ディレクトリを共通の祖先に対して再帰的に比較して、単一のパッチ ファイルを作成することです。

これを行う 1 つの方法は、共通の祖先の 2 つのコピーを作成し、2 つのコピーに異なるパッチを適用してから、meld を使用してマージを行うことです。meld は、変更されていないファイルの比較に多くの時間を費やしていました (dir には数千のファイルがあります)。これを行うより良い方法はありますか？

私はLinux初心者なので、正確なコマンドを入力していただければ幸いです。

状況は次のとおりです。上流のコード ベース (V1 から V2 へ) からの変更を、V1 から派生/分岐した 3 番目のコード ベース S1 にマージして、新しいコード ベース S2 を生成する必要があります。

V1 と V2 の間のログとリビジョン、および V1 のソース、V2 と S1 のソースのバージョン管理にアクセスできます。ただし、S1 にはバージョン管理リポジトリと履歴が提供されていません。V1 から S に到達するための中間変更が個別に認識されていないため、これをブランチと進化したトランクの間のマージとして扱うことはできません。

そのため、S1 で派生した変更が V2 に基づいて機能するように更新され、S2 を生成するためにインクリメンタル 3 ウェイ マージを実行しているという状況です。(私たちの進化する V2 は当然バージョン管理下に置かれます)

WinMerge は、ディレクトリ構造間で単純に異なる/欠落している/追加されているファイルを識別するのに役立ち、p4merge はファイル レベルでの優れた 3 方向マージ ツールとして使用できることがわかりました。

どのツールとテクニックを提案しますか? コード ベースのサイズが大きく、V1 と V2 の間の中間リビジョンの数が多く、V1 と S の間の変更のサイズも大きいことは注目に値します。

ウィキペディアによると、3 方向のマージは 2 方向のマージよりもエラーが発生しにくく、多くの場合、ユーザーの介入は必要ありません。これはなぜですか？

3 方向のマージが成功し、2 方向のマージが失敗する例が参考になります。

それぞれ3つのバージョン（元のバージョンと、各ファイルの2つの異なる変更バージョン）を持つバイナリ構成ファイルのセットがあります。2つのバージョンとオリジナルの違いをすべて同時に確認できる必要があります。

私が必要としているのは、バイナリファイル用の3者間差分ツールです。かなり疲れ果てたGoogle検索を通じて、私は最終的に、私が必要としていることを正確に実行するアプリケーションのスクリーンショットに出くわしました。残念ながら、画像を含むフォーラムの投稿には、使用しているアプリケーションが記載されていません。

http://www.xboxhacker.org/index.php?topic=15032.0

誰かが私を3つのバイナリファイルのバイナリセーフ（16進）比較を提供する（Windows）アプリケーションの方向に向けることができますか？

私は Git を学んでおり、このサイトのチュートリアルが非常に役立つと感じています。そのページには、マージに関して、次のものが含まれています。

マージコミットは (F) で、親 (D) と (E) があります。(B) は (D) と (E) の共通の祖先であるため、(F) のファイルには (B) と (D) の間の変更、つまり (E) のファイルに組み込まれた見出しの修正が含まれている必要があります。

共通の祖先 B について心配する理由がわかりません。D と E をマージして F を生成できないのはなぜですか? D は B から派生したものですが、必要な違いが含まれている可能性があります。B と D の間で多くのコミットが行われ、変更が行われて削除された可能性があります。