Subversionは両方向のマージを適切に処理できますか（トランク<->ブランチ）？

Question

私の知る限り理解し、Subversionの中にマージ&を分岐処理する最も一般的な（と推奨）の方法は次のとおりです。

• トランク
• のコピーはブランチ上の破壊的開発、および定期的な開発を行うようブランチを作成on trunk
• このようにしている間に、trunk - > branchの変更を定期的にマージして、分岐が大きくなりすぎないようにします。マージトラッキング（svn:mergeinfo）では、svn merge ^/trunkを実行するだけで、SVNはトランクからのすべてのアンマウントされた変更を自動的にフェッチします。
• ブランチの作業が完了したら、すべてをマージして（トランク上で：svn merge --reintegrate ^/branch/foo）、ブランチを破棄します。

（例えば、SVN本、Basic Mergingの章に記載されている）。

私の問題：これは「機能ブランチ」ではうまく機能しますが、時には出荷/出荷予定バージョンを表す「リリースブランチ」も必要になります。 （ - >トランク支店）時々

が、トランクにマージしなければならないのリリースブランチから

• バグ修正：私の経験のマージ中
  リリースブランチで

  は、両方の方向に起こることがありますトランク（または新しい機能）からのバグ修正は、リリースバージョン（またはリリースへのアップデート）にとって重要であるとみなされるので、トランク - >ブランチをマージする必要があります。

私は、 SVNとsvn:mergeinfoがこれを処理します。双方向でマージ（「双方向マージ」）しても、svnでマージされたリビジョンを追跡できますか？

落とし穴がありますか？何に注意を払うために特別な？

Answer 1

両方向（「双方向マージ」）でマージしても、svnでマージされたリビジョンを追跡できますか？

はい、個々の機能をマージして（特定のリビジョンをマージすることによって）、SVNはそれを追跡します。

Answer 2

実際にSVNで両方向にマージすると、多くの場合痛みが増えます（gitと比較して）。問題は、トランクをブランチにマージし、ブランチの変更をトランクにマージしようとすると、ブランチにマージされたトランクからの変更をマージして、多くの不要な競合が発生することです。この問題を回避するには、ブランチをトランクにマージする前に、トランクをブランチにマージした場所のコミットを「レコードのみ」にすることができます。 一般的なアプローチについては、SVNの本のAdvanced Merging - Blocking Changesの章を参照してください（ただし、提供するサンプルはその特定のユースケースではありません）。

例：

1. ブランチにトランクのあなたのマージを仮定は、（Iは、NetBeansを使用した場合、多くの場合、それは最初のディレクトリを作成し、ファイルのことを参照）2コミットr3857とr3858を作成しました。
2. 次に、あなたは、そのリリースブランチ上のいくつかの追加の修正をしました。

3. 今、あなたは戻ってトランクにマージします。その前に、あなたのトランクのディレクトリに次の操作を行います。

   のsvnマージ "^ /プロジェクト/支店は/リリース-0.1" を-r3857：3858は--record専用

4. その後リリース0.1からマージいつものように分岐します。これにより、直接マージの試みと比較して競合が少なくなります。

   （ツリーの競合が解決されたときに、いくつかの理由がファイルレベルでsvnmerginfoを導入するための特定のSVNのかもしれないで）私は時々導入された変更の一部を元に戻すコミットする前
5. 。