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

从SVN v1.5开始,合并是逐版本进行的。挑选要合并的区域将导致我们解决主干-分支冲突 两次 (将中继修订合并到FB时为一次,合并回FB时为一次)

那你做错了什么!

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

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

然后,当fb完成时,合并20-30,然后 复制

若你们决定只合并r11:20,那个么最后你们需要合并r1:10和r20:30 复制 从fb到后备箱。

您不可能合并更改两次!

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

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

只有一个方向。

正确的方法:

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

编辑

因此,正确的步骤是:

1. FB_0=trunk_0
   

2. 在FB上工作。

   FB_1=FB_0 + change_a
   

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

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

4. 在FB上工作

   FB_3 = FB_2 + change_b
   

5. 合并所有即将到来的 未合并的更改 从后备箱到FB。

   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
   

6. 在这一点上,我们有一个功能分支,它包括 新功能和 树干的变化。所以我们只是复制两个分支之间的差异。

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

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

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

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

http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature

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

编辑2: 对于svn-1.5

使用svn-1.5时,您可以更简单地合并:

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

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

再次确认一切都是最新的。你到后备箱去跑步

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

经研究后:

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

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

SVN扩展作为标准SVN客户端。它允许您继续使用SVN,同时获得Mercurial的文件夹处理能力。

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

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

我想我必须在这里为@Artyom辩护。我也认为如果必须的话

两次

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

我相信@Artyom可以写得更清楚的一件小事是,最终你“复制” fb trunk 您不使用 svn copy 但是 svn merge (或 svn merge --reintegrate ). 这可能是您在中找不到“复制合并”模式的原因 Common Branching Patterns .

以下是我听到的:

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

现在您有了一个新的分支(我们称之为b2),它相当于主干,对吗?及 哪里 是否需要“大量主干更改”?我想是在fb?

始终向下(特征分支->

但由于您刚刚从主干创建了b2,所以并没有任何东西可以合并到主干中,不是吗?您也不会将更改从b2合并到fb(因为这与将主干合并到fb相同…)。那么,“重大变化”是如何进入fb的呢?一旦它们存在,为什么要将它们合并回主干(因为它们最初来自主干)?

其实下面的链接 the section called “Tracking Merges Manually" 和/或 the section called “Merging a Whole Branch to Another" 常见分支模式 可能有助于解决一些问题。这些链接在1.5文档中“缺失”(可能是因为新的 --reintegrate 选择权 merge

你似乎真的在两次合并相同的更改,我真的认为你不应该(需要)这样做。