有一个非常大的Visual Studio解决方案（差不多200个项目）我需要重构和重组，合并并可能将许多项目分开，改变代码......
问题是 - 我将在代码的一个分支上工作，而另外几个分支机构将继续开发。在我的重构完成后，需要进行更改 应用于一些可能已经彻底改变的分支机构。此外，我的目录结构将发生巨大变化，其中许多部分已重命名或合并。
问题是 - 将来依靠SVN合并项目是否合理，还是需要外部工具？或者也许写自己的工具。
对不起基本问题，我对SVN比较新，不确定这是不是最好的方法。
答案 0 :(得分：2)
根据我的经验，依靠SVN合并你会做的事情（重构）你要做的事情（在分支机构工作）结果是极其反...生产性。
根据我的记忆，这样做会导致开发人员浪费大约1/4（如果不是1/3）来修复由SVN合并引入的回归错误（我们已经从JIRA得到了这些估计值。）
我们解决这个问题的方法是改变分支策略（如果你感兴趣的话，在网上搜索版本控制分支策略）。我们改变的策略是 unstable trunk （如果您有兴趣，这也是可搜索的术语）。这一转变需要非常明显的准备工作和开发过程中的一些变化（更多内容如下），但总体而言结果不仅令人满意 - IIRC 废物率下降超过4倍。
最值得注意的开发过程中的变化我上面提到的是常规的“检查点”主干版本和回归测试周期。我们引入这些作为自然检查点的替代，这些检查点之前是通过合并实施的。
...还是需要外部工具？
该选项看起来也值得考虑。我记得在我的项目切换到不稳定主干之后的某个时候，与前同事讨论SVN合并问题。他告诉我，对于他目前的项目，转向更好的合并工具有很大的不同。
当时我对我们所拥有的东西感到非常满意，所以我没有标记他所提到的工具。虽然在SO上似乎有很多相关的讨论，例如：
- What's the best three-way merge tool?
- Tools for SVN Merging
- Better Merge Tool for Subversion
PS。而且，无论您如何解决合并问题，拥有一套全面且易于使用的测试将非常有用