您的问题是您的工作流程。分支并非旨在以您使用它们的方式使用。您可以将更改从分支的源合并到分支（在您的示例中，/trunk），但是一旦将分支更改合并回源，您应该停止使用分支并将其删除。 （旁注：从技术上讲，keep a branch alive after reintegrating it 有一个“官方”方式，但由于它相当于删除和重新创建分支并且更难做到，因此通常不是最佳途径）
这里的问题是元数据。当您合并分支之间的更改时，Subversion 会记录元数据，指示合并了哪些修订。从分支合并回主干会将元数据附加到主干，指示合并了来自分支的某些修订。下次合并来自主干的更改时->分支，被合并的修订之一是代表分支-> 主干合并的主干修订。在这一点上，元数据相当混乱，几乎是循环的，你实际上可以通过合并自上次合并以来在分支中修改的旧代码位来破坏你的分支。即使合并成功完成，您也会增加未来合并发生冲突的可能性。一般来说，它非常容易出错，并且不是 Subversion 设计的用例。要更好地解释为什么这会导致问题，请参阅上面的链接。
一般来说，分支是为临时的、短期的开发工作而设计的。你正在做的事情听起来更像是一个长期的fork，而不是一个分支，这绝对不是 Subversion 的典型用例之一。这里有几个选项。
1) 当你从分支合并到主干时，不要记录任何关于合并的元数据。要么手动合并更改（而不是让 Subversion 来做），要么合并更改，然后在提交之前恢复元数据更改。这不是一个很好的解决方案，并引入了复制/粘贴错误的机会，但它可能会导致更少的问题。您仍在标准 Subversion 工作流程之外进行操作，因此我预计您仍会遇到问题。
2) 避免将分支部分合并回主干。如果合并所有分支的更改，请执行--reintegrate 合并，然后删除分支（您始终可以创建一个新分支，即使是同名分支）。如果只需要合并更改的子集，请在主干（而不是分支）中进行初始开发，然后将更改从主干合并到分支。这样一来，您所有的合并仍然朝着同一个方向进行，最终结果是主干和分支中都存在更改。
3) 考虑使用git。您所描述的工作流程更容易使用 git 完成，并且不涉及跳过尽可能多的箍来使其运行。您还可以在 Subversion 上运行 git，这样您就可以在本地计算机上使用 git 存储库，从 Subversion 存储库中提取和推送更改。
4) 通过重构代码消除对 fork 的需求，这样就不需要单独的分支。将通用功能分解为共享模块，并将差异隐藏在通用接口后面。如果您愿意，可以使用编译时标志来选择要构建的版本。这将完全消除进行合并的需要。
#4 显然是最好的解决方案。我知道不可能在所有情况下都做那种事情，特别是当代码库很大并且分支进行重大架构更改时。如果这是不可能的，我推荐选项#3。我个人使用这种方法。我的团队使用 Subversion 存储库，但团队中的几个开发人员——包括我自己——在我们的本地机器上运行 git，以便做一些 Subversion 不做（或不容易做）的更高级的事情。我们不像您那样维护任何长期分支，但我们经常使用多个短期分支并在它们之间合并更改。
有关 Subversion 有关分支和合并的典型用例的更详细描述，请参阅the Subversion book。