...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy
我发现这种方法在大型开发项目中非常不实用，原因有几个，主要与重新整合步骤有关。
相反，我们做我们称之为“重新分支”的事情。在这种情况下，当需要大量的主干更改时，从当前主干开放新的功能分支，并且合并始终向下（功能分支 - >主干 - >稳定分支）。这不符合SVN书籍指南，开发人员认为这是额外的痛苦。
你如何处理这种情况？
答案 0 :(得分：3)
从SVN v1.5开始，合并是由rev-by-rev完成的。挑选要合并的区域将导致我们解决主干分支冲突两次（一次将主干修订版合并到FB，再次合并时再次）
然后你做错了什么！
让我们看看：
trunk fb
---------\
r1-10 |
r11-20 |
r20-30 |
通常，如果您希望在11-20中完成更改，那么最佳做法是将1-20合并到fb 把一切都拿到那里。
然后当fb完成后，合并20-30然后复制 fb到trunk（不合并！）。
如果你决定只合并r11：20，那么，最后你将需要合并r1：10和r20：30 然后复制 fb到trunk。
您无法合并两次更改！
我假设你可能会这样做：
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_0=trunk_0
在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
在FB上工作
FB_3 = FB_2 + change_b
将所有即将发生的未合并更改从主干合并到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
此时我们有一个功能分支，其中包含所有新功能和 中继中的所有更改。所以我们只是复制两个分支之间的差异。
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
或者用普通语言来区分主干和分支并将它们放到主干上 使它们等效。
现在，如果这对你不起作用，那么我不明白这个问题。
编辑2：对于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
如果你的工作如图所示，在最后一个应该没有冲突。
答案 1 :(得分：1)
经过研究：
在visionmap，F2F讨论，包括Artyom，打开SVN书籍案例等的许多头脑风暴会议之后 - 看起来这是不可能做到的。功能分支完全不像工作副本。更新它的唯一有效方法是重新创建一个新分支，如上所述。
答案 2 :(得分：0)
我们是一家小公司，所以我不知道我们的解决方案是否适用于您的情况。我们所做的是从主干到稳定分支的转速合并。我们可以通过两种不同的方式实现： - 真的需要修复，我们在提交到trunk之后合并 - 危险的修理/改变。我们等待几天，直到更改在主干中被证明然后我们合并
通过这种持续的合并，我们避免了大量的冲突。
我的2美分。
答案 3 :(得分：0)
可悲的是，所提到的一切都可以被认为是黑客攻击。从分支机构的主干更新可能会在将其带回主干时导致非常严重的问题，并且可能导致最严重的冲突，树冲突。这是因为目录不被视为头等公民。最好的方法是使用Mercurial SVN扩展作为标准SVN客户端。它允许您在获得Mercurial文件夹处理功能的同时继续使用SVN。
然后在wworkstation方面，你可以使用多种方法，提供一系列功能，以适应SVN单一情况下的许多情况。您可以使用常规修补，修补程序队列，从本地中继副本进行更新，而不会影响共享主干和其他各种方法。
这种方法可以解决所有SVN的问题。由于类似情况，我不得不改用这种方法。即使你不立即使用这种方法，你至少应该尽快尝试。
答案 4 :(得分：0)
我想我必须在这里讨论@Artyom的问题。我也认为如果你必须
有些事是错的。我认为@Artyoms论证/解决方案非常可靠。解决主干分支冲突两次
我相信@Artyom可能写得更清楚的一件小事是，你最后将fb“复制”到trunk，你不会使用svn copy但{{1} （或svn merge）。这可能是您在Common Branching Patterns中找不到“复制合并”模式的原因。
由于我正在努力理解你到目前为止所做的事情，我不确定还能说些什么。
以下是我听到的内容：
相反，我们做我们所说的 “再分支”。在这种情况下，当一个 大量的树干变化是 需要，打开一个新的功能分支 来自当前主干，......
现在你有一个新的分支（我们称之为b2），相当于trunk，对吗？并且其中是“需要更改大量主干”？我假设在fb？
......合并是 总是向下（特征分支 - ＆gt; 主干 - ＆gt;稳定的分支机构）。
但是你刚刚从trunk创建了b2，没有什么可以合并到trunk中，不是吗？而且你也没有将变化从b2合并到fb（因为这与将trunk更换为fb相同......）。那么“重大的变化块”如何进入fb呢？一旦他们在那里，你为什么要把它们合并回主干（因为这是他们首先来自哪里）？
实际上，the section called “Tracking Merges Manually"下的SVN 1.4文档中提供了以下链接the section called “Merging a Whole Branch to Another"和/或Common Branching Patterns（我知道，您不使用SVN 1.4，但我相信它仍适用）帮助澄清一些事情。这些链接在1.5文档中“缺失”（可能是因为svn merge --reintegrate中的新--reintegrate选项）。
你似乎真的两次合并相同的变化，我认为你不应该（需要）这样做。