svn - 再統合オプションが本当に必要になるのはいつですか?

Question

機能ブランチをマージして戻す前に、常に機能ブランチを同期する場合。なぜあなたは本当に--reintegrateオプションを使わなければならないのですか？

Subversionの本には次のように書かれています：

ただし、ブランチをトランクにマージする場合、基礎となる数学はまったく異なります。機能ブランチは、複製されたトランクの変更とプライベート ブランチの変更の両方の寄せ集めになっているため、コピーする単純な連続した範囲のリビジョンはありません。--reintegrate オプションを指定することにより、Subversion に、ブランチに固有の変更のみを慎重にレプリケートするように依頼します。(実際、最新のトランク ツリーと最新のブランチ ツリーを比較することでこれを行います。結果の違いは、まさにブランチの変更です!)

したがって、この--reintegrateオプションは機能ブランチに固有の変更のみをマージします。しかし、マージの前に常に同期する場合 (機能ブランチでの競合に対処するために推奨される方法です)、ブランチ間の変更は機能ブランチに固有の変更のみですよね? また、Subversion がターゲット ブランチに既にあるコードをマージしようとしても、何もしませんよね?

ブログ投稿で、Mark Phippard は次のように書いています。

これらの同期されたリビジョンを含めると、トランクに既に存在する変更をマージして戻します。これにより、不必要で紛らわしい競合が発生します。

reintegrate を削除すると不必要な競合が発生する例はありますか?

Answer 1

を使用する必要はありません--reintegrate。それは便利です。最新の からtrunkへのマージが、 リビジョン への分岐以降にfeature-branch発生したすべての変更をマージした場合、次のコマンドを使用できます。trunkrev

svn merge url://trunk@rev url://feature-branch .

このコマンドは の最新の作業コピーのルートで実行され、trunkコミットされる未解決の変更がないことに注意してください。

「再統合を削除すると不必要な競合が発生する例はありますか?」という質問にもっと直接的に答えるために、私の答えを拡張させてください。

「これらの同期されたリビジョンを含めると、トランクに既に存在する変更を元にマージします。これにより、不必要で紛らわしい競合が発生します。」という記事の意味は次のとおりです。

同期されたリビジョンを含めると、次のようになります。

svn merge -r N:HEAD url://feature-branch .

はトランク.のクリーンな作業コピーで、はから作成されNたリビジョンです。このマージ コマンドは、 が作成された後にマージされた変更を含め、分岐後に にコミットされたすべての変更をマージします。つまり、すでに行われた変更は上記のマージに含まれます。Subversion に変更を適用するように指示することになり、実際には.feature-branchtrunkfeature-branchtrunkfeature-branchtrunktrunktrunk

Answer 2

Mark は、変更された 2 つのファイルの比較を避けることを意味していると思います。1 つはブランチから再統合され、対応するトランク内のファイルは、両方が同期されている場合です (それぞれのブランチでローカルに変更されているだけではありません)。

と がtrunk/a.cありbranches/dev/a.c、trunk/a.cある時点で変更され、後でマージしてブランチに再統合されたとします。ご指摘のとおり、すべてをトランクに戻す前にそれを行うことをお勧めします。

したがって、次のステップはa.c、両方の場所で変更されているため、両側で「異なる」トランクにマージすることです。このオプションがないと、不必要な比較が行われますが、 を指定する--reintegrateと、SVN は変更がローカルだけではないことがわかります。

Answer 3

使用する必要はありません--reintegrate— 単なるエイリアスです。の作業コピーがある場合はtrunk、

svn merge --reintegrate url://feature-branch workingcopy

と同じです

svn マージ url://trunk url://feature-branch workingcopy

使いやすい方を使用できます。