据我所知，处理分支的最常见（也是推荐的）方法是&Subversion中的合并是：
- 将分支创建为trunk的副本
- 在分支上进行破坏性开发，在主干上进行常规开发
- 在这样做的时候，定期合并trunk->branch，以避免分支分叉过多。使用合并跟踪（
svn:mergeinfo），我只需运行svn merge ^/trunk，SVN就会自动从trunk中获取所有未合并的更改 - 在分支上的工作完成后，将所有内容合并回（在trunk:
svn merge --reintegrate ^/branch/foo上），然后丢弃分支
（例如在SVN书的"基本合并"一章中进行了描述）。
现在我的问题是：虽然这对"功能分支"很有效，但有时也需要"发布分支"，它代表发货/即将发货的版本。
根据我的经验，对于发布分支，必须在两个方向进行合并：
- 发布分支中的错误修复必须合并到trunk中（branch->trunk）
- 但是，有时trunk中的错误修复（甚至是新功能）被认为是发布版本（或版本更新）的关键，因此必须合并trunk->branch
我还没有发现任何关于SVN和svn:mergeinfo将如何处理这一问题的确切信息。我可以双向合并（"双向合并"），并且仍然让svn跟踪合并后的修订吗？
有陷阱吗？有什么特别需要注意的吗？
实际上，在SVN中双向合并通常会导致更多的痛苦（与git相比）。问题是，如果将主干合并到分支，然后尝试将分支上的更改合并回主干，SVN将尝试将主干中的更改再次合并到分支中，这将导致许多不必要的冲突。为了解决这个问题，您可以"只记录"在将分支合并到主干之前将主干合并到分支的提交。请参阅SVN书中的Advanced Merging-Blocking Changes一章，了解一般方法（但他们提供的示例不适用于特定的用例）。
示例：
- 假设将主干合并到分支创建了两个提交r3857和r3858（我经常看到在使用NetBeans时，它首先创建目录，然后创建文件）
- 然后，您对该发布分支进行了一些额外的修复
-
现在您想将它合并回主干中。在此之前，请在主干目录中执行以下操作：
svn merge"^/project/branchs/release-0.1"-r3857:3858--仅记录
-
在那之后，像往常一样从版本0.1的分支进行合并。与直接合并尝试相比，这将减少冲突数量。
- 在提交之前，我有时会还原一些引入的更改（特别是SVN可能由于某些原因在解决了树冲突时在文件级引入svnmerginfo）
我可以双向合并（"双向合并"），并且仍然让svn跟踪合并后的修订吗？
是的，您可以合并单独的功能（通过合并特定的修订），SVN将跟踪这一点。