SVNブランチの繰り返しマージを処理する正しい方法は何ですか？

Question

ここには、新しいリリースで開発するためのトランクとブランチを持つSVNリポジトリがあります。

ブランチのリリースの準備がもうすぐできているので、ブランチをトランクに再統合することにしました。明らかにいくつかの矛盾がありました。トランクで削除されたファイルからの非常に多くのツリーの競合を含む。

すべての競合を十分に解決し、トランクをコミットしました。

問題は、ブランチにさらにいくつかのマイナーな変更を加えたため、ブランチを再度統合するために行ったところ、すべての同じツリーの競合が発生しました。それらを解決することは問題ではありませんが、非常に多くがあり、それらをすべて手動で確認して解決するのに時間がかかります。変更を加えて再統合するたびに同じ解決プロセスを実行する必要はありません。 SVNはブランチがすでに1回再統合されたことを認識し、最後の再統合が発生した時点からのみマージすることを期待していました。

リビジョングラフを開くと、トランクとブランチが分割されたポイントが表示されますが、マージは表示されません。すべきですか？

サーバー：WinServer2003（R2sp2）、VisualSVNServer（1.7.2）。 クライアント：WindowsXP（sp3）、TortoiseSVN（1.6.5）を使用してこのすべてを実行しましたが、コマンドラインクライアントもインストールしています。

私は、トランクが最新であることを確認し、TortoiseSVNを使用してマージを実行し、「ブランチの再統合」を選択してマージを実行します。オプションダイアログが表示されたとき。マージの深さを「作業コピー」に設定します

このシナリオを間違って処理していますか？何か違うことをすべきですか？

（リポジトリのレイアウトが間違っている可能性があります。トランクから分岐し、ブランチ内の新しいリリースのすべての変更を行いました。リリースはブランチをマージしてトランクに戻す予定です。間違ったアプローチ、私はいくつかの人々がそれを逆方向にやって、トランクですべての変更を行い、リリースの準備がほぼ完了してブランチがサポートされているリリースバージョンになったときにのみブランチを作ることについて読んだことがあります）

Answer 1

以下は、 SVNブックのこの章：

  

Subversion 1.5では、ブランチからトランクへの--reintegrateマージが行われると、ブランチは以降の作業に使用できなくなります。新しいトランクの変更を正しく吸収することも、トランクに再度適切に再統合することもできません。このため、機能ブランチで作業を続けたい場合は、それを破棄してからトランクから再作成することをお勧めします

Answer 2

この状況では、開発が完了するまで、ブランチからトランクにコードをマージしません。

Iトランクからブランチにマージして、ブランチがトランクに適用された修正で最新であることを確認します。 devブランチにすべての修正が含まれるように、このアクティビティを定期的に実行してください。次に、開発がライブリリースになる時点で、ブランチからトランクへのマージを1回限りのアクティビティとして実行します。

私の答えは、次のようないくつかの仮定を立てています：

• ライブトランクと開発者がいます ブランチ
• ライブは1つだけです バージョン（つまり、レガシーを維持しない バージョン）

役立つこと。

Answer 3

双方向のマージを繰り返すことが実際に可能になりました

注意事項。この回答は、それがどのように行われるかを説明していますが、ステップを逃した場合は申し訳ありません。たとえば、-reintegrateマージは、ブランチで作業を続けると--reintegrateマージステップで行った変更を静かに見逃してしまうため、完全に些細なものでなければなりません（すべての相違はブランチですでに解決されています）。代わりに--reintegrateの後に毎回ブランチを削除して再作成することです。

---

少なくともsvnバージョン1.6以降では、双方向のマージを繰り返し実行できます。 svn mergeを使用すると、「main」ブランチから子ブランチに何度でもマージできますが、ブランチをmainにマージするたびに、オプションを指定する必要があります

--reintegrate 他の回答で述べたように。

あなたがしなければならないことは、コマンドを使用して、2番目の手動ステップ（ブランチをチェックアウトおよび更新）で統合したことをブランチに伝えることです / p>

svn merge --record-only -c 391 ^/calc/trunk

391は、calc / trunkで行った--reintegrateブランチコミットのマージコミット番号を表します。

見逃した場合でも機能する場合があります。または、次にマージするときにすでに解決したマージの競合を再度解決する必要があります。記録のみのステップの後、ブランチはさらに作業またはマージできる状態になります。 馬鹿げています（特に私のように Git でだめにされている場合はうまくいきます）が、この儀式に従ってやると、両方のブランチが常に新しいコミットに対してオープンになります。

---

全体は、SVNブックの 2回再統合

  

このマージでは、導入されたチェリーピッキングマージ構文を使用します。   ＆＃8220; Cherrypicking＆＃8221;というセクションで。ランニングを続ける   ＆＃8220;ブランチの再統合＆＃8221;というセクションの例   リビジョンXはリビジョン391でした：

$ cd my-calc-branch $ svn update Updating '.': Updated to revision
393. $ svn merge --record-only -c 391 ^/calc/trunk
--- Recording mergeinfo for merge of r391 into '.':  U   . $ svn commit -m "Block revision 391 from being merged into my-calc-branch."
 Sending        .

 Committed revision 394.

  

これで、ブランチは再びトランクから変更を吸収する準備ができました。ブランチをトランクにもう一度同期した後、ブランチをもう一度再統合することもできます。必要に応じて、別のレコードのみのマージを実行して、ブランチを存続させることができます。すすぎ、繰り返します。