如何解决大型Subversion版本库中的合并问题？

Question

在我解释核心问题之前，让我说我真的很感兴趣将我们的源代码控制从Subversion迁移到Git/Mercurial，如果它真的是我们问题的更好解决方案，但我真的很想找到最好的解决方案，而不会对团队造成太多不必要的压力。 （换句话说，我不是在寻找“完全转储颠覆，并移动到Git的”的答案，因为这涉及到很多颠簸和陡峭的学习曲线。）

现在，这出的方式，这里是我们的核心问题：

我的开发团队正在处理一个相对较大的Subversion存储库，其中所有的开发过程都是直接在Trunk上完成的。来自上面的更快发布周期的请求使我们将我们的工作分解成单独的分支，每个分支包含创建分支时的Trunk镜像和每个分支并行工作的子小组。新的周期是发布一个特定的分支到生产环节，然后将新的更改合并到主干中，并将主干更改合并到其他分支中。

不幸的是，这已经成为一个非常痛苦且容易出错的过程，我们需要找到一种更好的方式来执行我们的合并，同时考虑到分支之间的简单变化，例如代码重新格式化（我们中有些人使用“清理代码“在我们的源文件上，有些则不）。总而言之，我们需要帮助确定一种更好的合并方式，而不需要我们的一个或多个开发人员花一整天手动解决冲突。

（很抱歉，如果这是一个有点含糊或散漫，我会很乐意澄清或应请求提供更多的细节。）

Answer 1

看看Subversion的文档在这里：http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html

我的建议是使用功能分支合并模式将分支合并到trunk中。从一个人执行较少的变化/伤害开始。

新周期是释放特定分支到生产，然后 合并的新变化到躯干，和躯干更改合并到每个 其它分支。

的特性分支合并格局，基本上颠倒顺序进行这些操作。

补充说明：“清理代码”是个好主意，只要大家在团队使用它之前提交。 Subversion（或任何其他VCS）不可能知道哪些更改是代码行为，哪些更改是为了美化。