Subversion，合并

Question

首先，让我先说明一下，我之前在这里问过类似的问题，但从未得到能解决我的问题或帮助我了解的答案。

首先，让我提出一个分支策略建议。这是我们在工作中使用的，如果有其他意见或为什么这很糟糕，请告诉我。但请理解，它通常对我们有效。

我们有一个产品，为了举例，我们称其为“PRODUCT”。我们运行两个并发开发周期。每周维护周期，在此期间我们修复非紧急错误；以及每两周的sprint。从主干创建了两个分支，称为“Sprint”和“Maintenance”（惊人的名称选择！）。此外，对于紧急/阻塞问题，修复将直接在主干上进行，并在测试后推送到生产环境。

当我尝试将sprint或maintenance重新整合回主干时，十有八九会出现大量冲突。即使其中一个分支从未处理过的文件也会出现冲突。这导致了大量手动合并，非常糟糕，并且往往会导致更多问题。

所以我将发布命令：svn merge --reintegrate http://repo/Sprint，虽然一些文件会更新，但在完全相同的文件上（通过WinMerge），我会遇到冲突。我不知道是什么原因导致了这些冲突。

我该如何停止出现这些荒谬的冲突？

- llaskin

---

如果没有一个具体的SVN命令序列和相应的编辑示例来引起这个问题，那么诊断起来会非常棘手... - Oliver Charlesworth

这可能是行尾符的问题吗？行尾符的更改在您的可视化差异工具中可能无法看到。 - Oliver Charlesworth

Answer 1

一个解决方案是使用许多小的特性分支，而不是两个固定的分支。你的问题在于来自固定分支的更改被合并，然后你在固定分支上做更多的更改，这些更改似乎与第一次合并发生冲突，即使它们实际上并没有冲突。

所以要么使用许多小的特性分支，要么切换到像Mercurial或git这样的DVCS，它比SVN处理合并更加智能。

- user2100815

---

不幸的是，由于我们使用了Atlassian Studio，SVN是我们所困扰的。 - llaskin

@llaskin 好的，那么使用特性分支。SVN 实际上是一个相当稳定的版本控制系统 - 你应该尝试使用原始 RCS、SCCP 或 PVCS，这些都是过去可怕的版本控制系统中的三个例子。 - user2100815

好的。所以每个分支都是从主干分支分出来的？还是我应该保留Sprint和Maint分支，然后从Sprint/Maint分支分出Feature分支？无论我选择哪种方式，我都可以看到这很快会变得非常复杂。 - llaskin

如果分支很小，那么它并不复杂 - 一个特性分支可能只用几个小时。但是我可能不是最好的人来提供建议，因为我怀疑你不是在运行 C++ 应用程序商店。 - user2100815

@llaskin：一旦您执行svn merge --reintegrate，您已合并的分支就不应再使用了，因为您不能再从中进行自动重新集成合并。请参见http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html。 - Oliver Charlesworth

Answer 2

你可能会对Timpani Software的MergeMagician项目感兴趣。它是一个与Subversion（以及Microsoft TFS）配合使用的分支管理和自动合并解决方案。您可以在分支之间创建发布/订阅关系，然后服务器自动执行合并。

频繁合并可以减少合并冲突的发生，而当它们发生时，MM提供了一个基于Web的机制来解决它们。

顺便说一下，这是一个商业工具。我听说过唯一一个类似的开源工具是Merge Fairy，但我认为Merge Fairy的开发活动不是很活跃。

请访问http://www.timpanisoftware.com查看详情。

- user292103

Answer 3

你可能只需要将主干合并回分支，而不是创建新的分支...就像这样：

主干 --- 创建冲刺

--- 将冲刺合并到主干 --- 将主干合并到冲刺

- rhinoinrepose