Svn 在多个分支上进行重构，并对目录结构进行大量更改

有一个非常大的VisualStudio解决方案（将近200个项目），我需要对其进行重构和重组，合并并可能分割其中的许多项目，修改代码

问题是-我将在代码的一个分支上工作，而更多的分支将随着开发而前进。在我的重构完成之后，需要修改 应用于其中一些分支，这些分支可能已经发生了巨大的变化。此外，我的目录结构将发生巨大变化，其中许多部分将被重命名或合并

问题是-将来依靠SVN合并项目是合理的还是我需要一个外部工具？或者写我自己的工具

---

对不起，基本的问题是，我对SVN比较陌生，不确定这是否是最好的方式。

根据我的经验，依赖SVN合并，就像你将要做的事情（重重构）那样（在分支机构中工作），结果是非常适得其反

据我回忆，这样做会导致开发人员在修复SVN merge引入的回归错误上浪费大约1/4（如果不是1/3的话）的时间（我们从中得到了这些估计）

• 当我第一次注意到这个问题时，我最初的假设是，这只是一个学习曲线的问题——我希望在获得足够的经验后，我们会发现如何正确地做这件事。不幸的是，即使在项目实施数月后，“废物率”仍保持在最初的水平

我们摆脱困境的方法是改变分支策略（如果您感兴趣，可以在web上搜索类似版本控制分支策略的内容）。我们改变的策略是不稳定的主干（如果您感兴趣，这也是一个可搜索的术语）。这一转变需要相当显著的准备工作和开发过程中的一些变化（更多信息见下文），但总体结果非常令人满意——IIRC废物率下降了4倍多

我上面提到的开发过程中最值得注意的变化是定期的“检查点”主干发布和回归测试周期。我们引入这些检查点是为了替代以前由合并强制执行的自然检查点

…还是需要外部工具

这一选择看起来也值得考虑。我记得在我的项目切换到不稳定主干后的一段时间，我与一位前同事讨论了SVN合并问题。他告诉我，对于他目前的项目，切换到更好的合并工具起了很大的作用

当时我对我们拥有的东西很满意，所以我没有标出他指的是什么工具。虽然SO似乎有很多相关的讨论，例如：
-
-
-

---

另外，无论您如何处理合并问题，拥有一套全面且易于使用的测试将非常有帮助