开始之前的一个简短说明：“设置舞台”需要很多解释，看起来这更像是一个设计问题，而不是一个关于编程问题的问题。这个问题其实是关于SVN分支和合并的，所以请读到最后。
设想：
我有一个包含很多项目的大型 Visual Studio 解决方案。我用的是SVN，所以主干当然有我开发的生产线。这包括一个核心 DLL 程序集、一个“主”UI 用户客户端和一些“插件”程序集，这些程序集通过在核心程序集上实现接口以在 UI 中提供功能，并且还通过利用一组服务来操作为所有插件提供通用功能的方法（例如持久性逻辑操作、集中式文件存储架构的存储操作等）
随着时间的推移，我还构建了一些外部实用程序，它们必须复制插件中的许多业务逻辑。我不会详细介绍，因为它最终会分散我的主要问题，而只是想象一下，例如，处理与特定插件数据相关的集中维护操作的服务器上的预定服务。
当我最初构建这个应用程序时，我（愚蠢地）没有预料到需要集中服务层，所以我构建了核心组件（无论好坏），如上所示，与应用程序的表示层紧密集成. 换句话说，将插件与用户界面集成所需的 UI 表示逻辑以及插件执行常见插件逻辑操作所需的业务逻辑都是一个“核心”组件的一部分。因此，插件和集中式服务之间存在的许多“共享”逻辑导致了重复代码。
我决定进行主要的重构计划，将通用逻辑——与演示无关的逻辑——提取到一个“共享”程序集中。为此，我从主干上创建了一个分支。我将公共代码重新组织为“共享”程序集，并重新指向客户端应用程序（插件等）和外部服务应用程序中的所有内容以利用共享程序集。在许多情况下，我还必须重命名类以适应它们未来更通用的用途。核心组件保留在原位，仅用于代理插件和 UI 之间的表示层职责。
问题：
现在我已经成功地完成了重构，我想将分支重新集成回主干。即使在简单的情况下，合并也是一件棘手的事情，但我在这里面临的是很多树冲突，委婉地说。此外，除了驻留在一个全新的项目中之外，“共享”项目中的文件夹结构与“核心”项目中的文件夹结构有很大不同。在许多情况下，由于使用共享程序集的新机制，类位于不同的位置。
我想维护每个类的版本历史，从核心程序集中的旧家到共享程序集中的新家。此外，我想保证合并成功。这似乎很明显，但在测试整个场景的微型版本时，我永远无法以我的分支功能保持完整不变的方式解决冲突。此外，正如我之前所说，我已经重命名了一些类以适应它们更一般的角色，这使得维护版本历史变得非常棘手。
我会注意到我正在使用AnkhSVN，当您重命名文件以修复移动时，它有助于“正常”情况，但它似乎不适用于这些主要的树冲突情况。另外，我知道不同版本的 SVN 之间的合并工作方式存在差异——我相信它是 SVN 1.5 之前的版本和 SVN 1.5 之后的版本。我正在使用 SVN 1.9.3。
几个星期以来，我一直试图弄清楚这一点。我一直在翻阅SVN 书籍、TortoiseSVN 资源，以及任何我可以从谷歌搜索中找到的东西，比如this、this和this —— 还有很多很多很多其他的。我觉得我快疯了，我认为高级 SVN（和 Tortoise）不可能用传统的自学、从网络和书籍中学习的方法来学习。无论如何，我将非常感谢那里的任何见解。
当您使用 SVN 创建功能分支并计划进行主要的树更改和“移动”（即重命名）以便您可以将这些更改与主干重新集成而不会丢失任何内容时，正确的方法是什么？