Svn 如何从主干正确更新功能分支？

:

…考虑此模式的另一种方式是，主干到分支的每周同步类似于在工作副本中运行svn更新，而最后的合并步骤类似于从工作副本运行svn提交

我发现这种方法在大型开发中非常不实用，原因有几个，主要与重新融入步骤有关

从SVN v1.5开始，合并是逐版本进行的。Cherry挑选要合并的区域将导致我们两次解决主干分支冲突（一次是在将主干修订合并到FB时，一次是在将主干修订合并回FB时）

存储库大小：对于大型代码库来说，主干更改可能非常重要，从其他主干复制差异文件（与SVN copy不同）可能会带来很大的开销

相反，我们做我们称之为“重新分支”的事情。在这种情况下，当需要对主干进行大量更改时，将从当前主干打开一个新的要素分支，合并将始终向下（要素分支->主干->稳定分支）。这并不符合SVN手册的指导原则，开发人员将其视为额外的痛苦

---

您如何处理这种情况？

我们是一家小公司，所以我不知道我们的解决方案是否适用于您的情况。我们所做的是从主干到稳定分支逐级合并。我们可以通过两种不同的方式实现： -真的需要修复，我们在提交到主干后合并 -危险的修正/改变。我们等了几天，直到更改在主干中得到验证，然后合并

通过这种持续的合并，我们避免了大量的冲突

我的2美分

从SVN v1.5开始，合并是逐版本进行的。选择要合并的区域将导致我们解决主干分支冲突两次（一次是在将主干修订合并到FB时，一次是在将主干修订合并回FB时）

那你做错了什么

让我们看看：

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

通常，如果您希望在11-20中完成更改，那么最佳实践是将1-20合并到fb 把所有的东西都送到那里

然后，当fb完成时，合并20-30，然后将fb复制到中继（无合并！）

若你们决定只合并r11:20，那个么最后你们需要合并r1:10和r20:30 然后将fb复制到主干

您不可能合并更改两次

我假设您可能会执行以下操作：

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

你不能这样做，因为你要合并11:20两次。您应该始终在中合并代码 只有一个方向

正确的方法：

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

编辑

因此，正确的步骤是：

从主干创建要素分支（FB）（使用svn copy将主干复制到要素分支）

在FB上工作

FB_1=FB_0 + change_a

将所有即将进行的更改从主干合并到FB

trunk_1=trunk_0 + tr_change_a;
FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a

trunk_2=trunk_1 + tr_change_n;
FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b

在FB上工作

FB_3 = FB_2 + change_b

将所有即将进行的未合并更改从主干合并到FB

trunk_1=trunk_0 + tr_change_a;
FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a

trunk_2=trunk_1 + tr_change_n;
FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b

此时，我们有一个功能分支，它由所有新功能和 主干中的所有变化。所以我们只是复制两个分支之间的差异

trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b

现在FB已删除，因为trunk已完成我们需要的所有更改

最后一步由以下人员执行：

svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
svn ci

或者在普通语言中，把树干和树枝的区别放在树干上 使它们相等

中描述了此模式

如果这对你不起作用，那么我不理解这个问题

Edit2:用于svn-1.5

使用svn-1.5时，您可以更简单地合并：

在处理要素分支时，只需不时合并主干的更改：

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

它将使您的FB与后备箱中的所有更改对齐。在FB结束时，运行此过程 再次确认一切都是最新的。你到后备箱去跑步

$ svn merge --reintegrate /path/to/fb
$ svn ci

---

在最后一个例子中，如果您按照图中所示的方式工作，应该不会有冲突。

遗憾的是，所提到的一切都可以被认为是黑客行为。从分支上的主干进行更新可能会在将其带回主干时导致非常严重的问题，并可能导致最严重的冲突，即树冲突。这是因为目录不被视为一等公民。最好的方法是将Mercurial与 SVN扩展作为标准SVN客户端。它允许您继续使用SVN，同时获得Mercurial的文件夹处理能力

然后，在wworkstation端，您可以使用多种方法，这些方法提供了一系列特性，可以在SVN的单一方法基础上适应多种情况。您可以使用常规修补、修补队列、从主干的本地副本进行更新，而不会影响共享主干和其他各种方法

---

这种方法适用于SVN的所有不利方面。由于类似的情况，我不得不改用这种方法。即使你不立即使用这种方法，你至少应该尽快尝试一下。

我想我必须在这里为@Artyom付出努力。我也认为如果必须的话

两次解决主干分支冲突

有点不对劲。我认为@Artyoms的论点/解决方案非常可靠

我相信@Artyom可以写得更清楚的一件小事是，在最后，当你将

fb

复制到

trunk

时，你不会使用

svn copy

，而是

svn merge

（或者

svn merge——重新整合

）。这可能是您在中找不到“复制合并”模式的原因

直到现在我还在努力理解你在做什么，我不知道还能说些什么

以下是我听到的：

相反，我们做我们称之为 “重新分支”。在这种情况下，当 主干更改的重要部分是 如果需要，将打开一个新的功能分支 从当前主干

现在您有了一个新的分支（我们称之为b2），它相当于主干，对吗？“需要大量主干更改”在哪里？我想是在fb

…合并是 始终向下（特征br