有一个非常大的 Visual Studio 解决方案（几乎 200 个项目），我需要对其进行重构和重组、合并并可能划分其中许多项目、更改代码......
问题是 - 我将处理代码的一个分支，同时还有更多的分支机构将继续发展。我的重构完成后，需要进行更改
适用于其中一些分支，这些分支可能已经发生了巨大的变化。另外，我的目录结构将发生巨大变化，其中许多部分被重命名或合并。
问题是 - 将来依靠 SVN 合并项目是否合理，还是需要外部工具？或者也许编写我自己的工具。
抱歉问这个基本问题，我对 SVN 比较陌生，不确定这是否是最好的方法。
There is a very large Visual Studio solution (almost 200 projects) which I need to refactor and restructure, merging and possibly dividing many of those projects, altering code...
The issue is - I am to be working on a branch of the code, while several more branches will be moving forward with development. After my refactoring is complete, the changes need to be
applied to some of those branches, which might been have drastically changed. Also, my directory structure will changed dramatically, many parts of it renamed or merged.
The question is - is it reasonable to rely on SVN to merge the projects in the future or do I need an external tool? Or perhaps writing my own tool.
Sorry for the basic question, I am relatively new to SVN and not sure if it is the best way to go.
发布评论
评论（1）
根据我的经验，依赖 SVN 合并（大量重构）就像您将要做的事情（在分支中工作）一样，结果极其适得其反。
根据我的回忆，这样做会导致开发人员浪费大约 1/4（如果不是 1/3）时间来修复 SVN 合并引入的回归错误（我们从 JIRA）。
我们摆脱困境的方法是更改分支策略（如果您有兴趣，可以在网络上搜索诸如版本控制分支策略之类的内容）。我们更改的策略是不稳定的主干（如果您感兴趣的话，这也是可搜索的术语）。这种转变需要相当明显的准备工作和开发流程的一些改变（更多内容见下文），但总体结果非常令人满意 - IIRC 废物率下降了 4 倍以上。
我上面提到的开发流程中最值得注意的变化是定期的“检查点”主干版本和回归测试周期。我们引入这些来替代之前通过合并强制执行的自然检查点。
这个选择看起来也值得考虑。我记得在我的项目切换到不稳定的主干后一段时间，我与一位前同事讨论了 SVN 合并问题。他告诉我，对于他当前的项目，改用更好的合并工具产生了很大的不同。
当时我对我们拥有的东西很满意，所以我没有标记他提到的工具。尽管 SO 似乎有很多相关讨论，例如：
- 最好的三向合并工具是什么？
- SVN 合并工具
- 更好的 Subversion 合并工具
PS。而且，无论您如何解决合并问题，拥有一套全面且易于使用的测试都会非常有帮助
In my experience, relying on SVN merge in stuff like you're going to do (heavy refactoring) the way you're going to do it (working in branches) turned out extremely counter-productive.
Per my recollection, doing things that way lead to developers wasting about 1/4 if not 1/3 time on fixing regression bugs introduced by SVN merge (we've got these estimates from JIRA).
Our way out of this mess was to change branching strategy (search the web for something like version control branching strategy if you're interested). Strategy we changed to was unstable trunk (this is also searchable term in case if you're interested). That switch required quite noticeable efforts to prepare and some changes in dev process (more on that below) but overall the result turned out more than satisfactory - IIRC waste rate dropped by more than 4x.
Most notable of changes in dev process I mention above are regular "checkpoint" trunk releases and regression test cycles. We introduced these to act as a replacement to natural checkpoints which were previously enforced by merges.
That option looks worth considering, too. I remember discussing SVN merges issues with an ex-colleague some time after my project switched to unstable trunk. He told me that for his current project, switching to better merge tool made a big difference.
Back then I was happy enough with what we had so I didn't mark what tool he referred to. Though there seem to be plenty related discussions at SO, for example:
- What's the best three-way merge tool?
- Tools for SVN Merging
- Better Merge Tool for Subversion
PS. And, no matter how you work around merging issues, having a comprehensive and easy to use set of tests would be really helpful