如何从trunk中正确更新一个功能分支？
SVN书说：
...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图书指南，开发者认为这是额外的痛苦。
你如何处理这种情况？
从SVN v1.5开始，合并完成了rev-by-rev。 樱桃采摘要合并的区域将导致我们两次解决树干分支冲突（一个是将中继修订合并到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_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被删除，因为中继线有我们需要的所有变化
最后一步是通过执行：
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
它会将您的FB与主干中的所有更改对齐。 在FB的结尾处，您再次运行此过程以确保所有内容都是最新的。 你去干线跑
$ svn merge --reintegrate /path/to/fb
$ svn ci
如果您按照所示的方式工作，则最后一项应该没有冲突。
经过研究：
在visionmap进行了许多集思广益会议之后，包括Artyom在内的F2F讨论，打开SVN书籍案例等 - 看起来这是不可能的。 功能分支完全不像工作副本。 如上所述，更新它的唯一工作方式是重新创建一个新分支。
我们是一家小公司，所以我不知道我们的解决方案是否适用于您的情况。 我们所做的是从主干向稳定分支合并的rev-rev。 我们可以通过两种不同的方式来做到这一点： - 确实需要修复，我们在进入后备箱后合并 - 危险的修复/更改。 我们等了几天，直到变更在主干中被证实，然后我们合并
随着这种持续的合并，我们避免了大量的冲突。
我的2美分。
链接地址: http://www.djcxy.com/p/44365.html上一篇: How to properly update a feature branch from trunk?
下一篇: How to avoid gcc warning in Python C extension when using Py