サブバージョンのマージ動作に関する私の観察に基づく短い回答(本/ソースの知識ではありません):
明示的なリビジョンを含むマージは、以前のマージを完全に認識していないようで、マージを行うたびに変更を再適用します。
リビジョン範囲のない「通常の」マージは、どのリビジョンがすでに (そのターゲットブランチに) マージされたかを認識しています。通常、変更が 2 回適用されることはありません。ただし、マージ対象の変更が、現在マージ ターゲットとなっている同じブランチで発生したかどうかはチェックしません。これが発生すると、ある種の状況依存のマージが行われますが、競合は神経質にならずに頻繁に発生します。
merge --reintegrate は、マージ ターゲットの過去に起因する変更を検出でき、それらを再適用しません。残念ながら、再統合は機能ブランチに対してのみ機能します。
タイプ 1 のマージはできる限り避けようとしています。2.「通常の」マージは、一方向のみにマージすることで飼いならすことができます。再び上下にマージすると問題が始まります。機能分岐シナリオのように「クロスマージ」する必要があるときはいつでも、マージ タイプ 3 を使用するか、リビジョン ブロッキングを使用したチェリーピッキング (--record-only を使用した明示的なリビジョン範囲マージ) を使用します。
SVNは、幅広いマージ操作を「盲目的に」サポートすることはできません:)。競合する人間の決定をすべて解決できる VCS はありません。
svn マージが競合する理由
その特定の「競合性」の理由の一部は、転覆の歴史に見られます。SVN 1.5 より前では、明示的なマージのみがありました。すでにマージしたリビジョンの範囲を知り、その知識に基づいて次のマージを行う必要がありました。そうしないと、説明した競合が発生します。
1.5 より前の SVN でのマージは次のようになります。
(ブランチの HEAD リビジョンは 510 です) svn merge -r500:510 http://server.tld/branches/stable-1.0
次のマージは次のようになります。
(ブランチの HEAD リビジョンは 520 です) svn merge -r510:520 http://server.tld/branches/stable-1.0
この構文は現在も有効で機能しています。
私が svn 1.4 のベスト プラクティスで説明したことについて読むことができます: (注意、レガシー リンク!) http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges .bestprac.track
SVN 1.5 で導入されたマージ機能により、あなたの意図のいくつかを測定し始めました。たとえば、SVN は自動的にマージする範囲を定義する計算を行い、何がどこでマージされたかを追跡します。オーバーヘッドが減り、人的ミスによる競合が減ります。しかし、多くのブランチを使用している場合でも、変更を 2 回適用したい場合があります。Subversion はその能力を維持しました。
それと一緒に暮らす方法
4 ステップの例で行うチェリー ピッキングは、トランクとブランチをかなり「タイト」に保ちます。ステップ 3 では、2 つのブランチが同一であるため、ステップ 4 でマージしても意味がありません。あなたが単純化したことは知っていますが、実際のシナリオではさらに多くの変更があるでしょう。しかし、Subversion ブランチの主なアイデアは分離することです。不安定、互換性のない開発、カスタムビルドからの安定...
チェリー ピック/クロス マージの必要性は、多くの場合、ブランチとブランチの使用に関するポリシーが十分に考慮されていないことの兆候にすぎません。
ブランチがクロストレードで頻繁に変更される場合は、それらを 1 つにすることができます。
私は講義をやめます;-) この時点で、私があなたをあまり混乱させなかったことを願っています.
svn のベスト プラクティスについて詳しく知りたい場合は、私の SO-Answers または SVN Red book で見つけることができるかもしれません。問題がある場合は、適切なチェリーピッキングに関する図を投稿できます。
乾杯