3

在 svn 书（http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html）中，在 Common Branching Patterns 部分中，它说：

主干被复制到“发布”分支。当团队认为软件已经准备好发布（比如 1.0 版本）时，/trunk 可能会被复制到 /branches/1.0。

团队继续并行工作。一个团队开始对发布分支进行严格的测试，而另一个团队继续在 /trunk 上进行新工作（例如，对于 2.0 版）。如果在任一位置发现错误， 则会根据需要来回移植修复程序。然而，在某些时候，甚至该过程也会停止。该分支在发布之前被“冻结”以进行最终测试。

（强调我的）。我假设维护分支与发布分支相同..？（我们需要在开发他们的下一个版本时让一个客户保持在以前的版本）。

我很确定我不应该使用--reintegrate，但我不太确定如何以不会弄乱未来合并的方式进行合并。我是否需要手动跟踪修订范围？..或者颠覆会为我做这件事（我使用的是1.7.6版）。

[编辑：更多细节]

trunk> svn mkdir c
trunk> touch a.txt b.txt c\d.txt
trunk> svn add a.txt b.txt c\d.txt
trunk> svn ci -m "initial trunk"
...
Committed revision 9580.

trunk> svn copy .../trunk .../branches/branch1 -m "create maint branch"
Comitted revision 9581.

trunk> svn rm c\d.txt
trunk> svn ci -m "Fix bug-1."
Deleting       c\d.txt

Committed revision 9582.

branch1> svn merge .../trunk
--- Merging r9581 through r9582 into '.':
D    c\d.txt
--- Recording mergeinfo for merge of r9581 through r9582 into '.':
 U   .

branch1> svn ci -m "Merged fix for bug-1 from trunk."
Deleting       c\d.txt
Committed revision 9583.

branch1> svn propget svn:mergeinfo .
/svntests/trunk:9581-9582

trunk> svn up
Updating '.':
At revision 9583.

【原问题】

trunk> svn merge .../branches/branch1
--- Merging r9581 through r9583 into '.':
   C c\d.txt
--- Recording mergeinfo for merge of r9581 through r9583 into '.':
 U   .
Summary of conflicts:
  Tree conflicts: 1

[来自@JB Nizet 的修复]

trunk> svn merge -c 9583 --record-only .../branch1
--- Recording mergeinfo for merge of r9583 into '.':
 U   .

trunk> svn propget svn:mergeinfo .
/svntests/branches/branch1:9583

那么来自维护分支的未来合并将起作用（正确更新主干上的合并信息）而不会产生冲突：

trunk> svn merge .../branch1
4

1 回答 1

3

发布分支用于准备发布的最后步骤。发布完成后，维护分支用于修复错误。它们都是分支，这纯粹是语义上的差异，但仍然是不同的。

要合并您的错误修复，您只需确保您的工作副本指向主干（目标分支），然后从维护分支（或维护分支的修订范围，如果您不希望所有内容合并）合并：

svn merge url_of_the_maintenance_branch

下一次合并会记住这些修订已经合并到主干，并会自动跳过它们。

于 2012-09-23T08:55:57.120 回答