問題タブ [three-way-merge]

これまでのところ、Evolphin Zoom でテキスト ファイルの競合を解決する際に、MacOS XCode FileMerge/OpenDiff ツールをデフォルトの 3 方向マージ ツールとして使用してきました。DiffMerge やその他の 3 ウェイ マージ ツールを使ってみた人はいますか? FileMerge が意味をなさない奇妙なマージを行っていることがわかりました。Evolphin Zoom では他のマージ ツールをプラグインできるため、MacOS で最適なオプションは何かを知りたいと思いました。Diffmerge はオープン ソースです。複雑なマージ シナリオでうまく機能しましたか?

複雑なhgリポジトリで複雑なマージを実行しようとしています。Mercurialがマージを実行するための「ベース」として使用することを選択した「最新の共有祖先」には満足していません。

ベースとして使用するために、自分で選択した特定のコミットを指定したいと思います。

これは可能ですか？もしそうなら、どのように？

これは説明が難しい状況ですので、ご容赦ください。デフォルトとdevの 2 つのメインブランチを持つ Mercurial リポジトリがあります。

通常、作業はdevの名前付きブランチ(機能ブランチ) で行われます。一度に多数のフィーチャー ブランチが存在する場合があります。そのブランチで作業が完了すると、devにマージされます。

リリースを準備するときが来ると、別の名前付きブランチがdevから作成されます(リリース ブランチ)。リリースから機能全体を除外する必要がある場合があります。その場合、feature ブランチがdevにマージされた場所からのマージ変更セットは、新しいリリース ブランチから取り消されます。

リリース ブランチをリリースする準備が整うと、デフォルトにマージされます(したがって、デフォルトは常に本番環境でのコードの状態を表します)。作業は、devブランチと機能ブランチで通常どおり続行されます。

この問題は、以前のリリースで取り消された機能を含め、別のリリースを行うときに発生します。新しいリリース ブランチが通常どおり ( devから) 作成されます。この新しいリリース ブランチには、以前のリリース ブランチからバックアウトされた機能が含まれるようになりました (リリース ブランチでバックアウトが実行され、マージ変更セットがdevブランチに残っているため)。

今度は、リリース ブランチがリリースの準備ができて default にマージされるとき、以前のリリース ブランチでのマージ バックアウトの結果としてバックアウトされた変更は、 defaultにマージされません。これはなぜですか？新しいリリース ブランチにはフィーチャー ブランチの変更セットがすべて含まれているため (何もバックアウトされていません)、なぜデフォルトブランチもこれらの変更セットのすべてを受け取らないのでしょうか?

上記のすべてを理解するのが難しい場合は、基本的な問題を示す TortoiseHg のスクリーンショットをご覧ください。「branch1」と「branch2」はフィーチャー ブランチ、「release」と「release2」はリリース ブランチです。

私は公式のPurdue RCS ホームページから Windows 用の GNU RCS バージョン 5.7 を使用しています。rcsmerge(1) コマンドを使用して異なるブランチからの変更をマージすると、次のエラーが発生します。

毎回。なぜこれが起こるべきなのか（少なくとも10年前にこの問題が議論されているのを見たことがあります）、修正方法を知っている人はいますか? GNU 現在の RCS リリース 5.8.1 では修正されていますか? もしそうなら、誰かがこのリリースの Windows バイナリを教えてくれますか?

2012 年 10 月 22 日更新: 現在の GNU diffutils 2.8.7 と同等の Purdue ディストリビューションで提供される diifutils(cmp、diff、diff3、merge) を切り替えました。これでsubsidiary program failedエラーはなくなりましたが、今The filename, directory name, or volume label syntax is incorrect.では rcsmerge または diff3 の呼び出しごとに正確に 2 回発生しています。これは Windows のエラー メッセージのようです。

私はファイルの 3 つのバージョンを持っています。オリジナル、私の変更、および他の人の変更です。3 方向マージを実行して、両方の変更セットを組み込んだバージョンを作成したいと考えています (または、これが不可能な場合は失敗します)。svn や git などのリビジョン管理システムについて質問しているわけではないことに注意してください。3 つのファイルを入力として取り、マージを標準出力に書き込む最小限のコマンドライン ツールを作成したいと考えています。

1 つの方法は次のとおりです。Unix の diff ツールと patch ツールを使用します。3 つのファイルの名前が orig、my、other であると仮定します。

% diff -u orig my | パッチ -o - その他

またはその逆を行うと、

% 差分 -u 元の他の | パッチ -o - 私

しかし、差分とマージを行うには 2 つの方法があるという事実は、コードの匂いのようなものです。確かに、3 つのファイルすべてを入力として受け取るマージ ツールの方が、より適切に機能する可能性があります。

明らかに、空の svn リポジトリを初期化し、orig をチェックインし、別のブランチで my と other をチェックインしてから、マージを実行できます。または、別のバージョン管理システムでの同等の操作。しかし、それは重くて扱いにくいようで、すぐに破棄されるリポジトリを作成します。

コマンド ラインからスタンドアロンで実行できる適切な 3 方向マージ ツールはありますか?

たとえば、ベース バージョン X と 2 つの異なる派生バージョン A および B の間で (Python で) 3 方向の差分/マージ アルゴリズムを実装しようとしていますが、いくつかの変更を処理する方法がわかりません。

X から A へ、および X から B への行ごとの差分があります。これらの差分は、行ごとに=、行が変更されていない+場合、行が追加された場合-行が削除されたc場合、および行が変更された場合 (単に の-直後に が続き+、行が削除されてから置き換えられ、効果的に変更されたことを示します)。

現在、A-diff と B-diff の対応するオペコードを比較して、それらをマージする方法を決定しようとしています。これらのオペコードの組み合わせのいくつかは簡単です:どちらのバージョンも行を変更していないこと=を意味するため、元のコードを保持します。とは、一方に行が追加され、他方には変更が加えられていないことを意味するため、追加を受け入れて、行を追加した側のみ次の行に進みます。とは、一方の行が変更され、もう一方の側で同じ行が削除されたため、ユーザーが解決しなければならない競合です。=+=-c

+しかし、 aと a -、または a+と aをどうするかで苦労していcます。たとえば最初のケースでは、片側に新しい行を追加し、反対側で後続の行を削除しました。厳密には、これは競合ではないと思いますが、追加がその行があることに依存しているとしたらどうでしょうか? それは全体に当てはまると思います（ある場所に追加されたものは、別の場所にあるものに依存して意味をなす場合があります）。2 番目のケースも同様で、片側に行を追加し、反対側に後続の行を変更しましたが、追加は行の元のバージョンに依存している可能性があります。

これを処理するための通常のアプローチは何ですか？