我们有一个相当典型的SVN存储库设置，^/trunk持有我们软件的当前稳定版本，以及位于^/branches/<feature>下的功能分支中的开发/错误修正。分支与主干保持同步，一旦分支功能完成，它必须通过一系列测试才能重新集成到^/trunk。
但有时，我已完成^/branches/A中的某项功能，并希望处理^/branches/B中的其他功能（取决于A ），在其自己的分支中，在分支^/branches/A可以重新集成到^/trunk之前。从一个分支到另一个分支获取功能的最佳实践是什么，而不是“打破”历史记录而不是必要的？
只是为了澄清我对“休息”的意思：我的目标是当^/branches/A最终重新融入^/trunk时，我会从trunk合并到{{1} }，它不应该产生任何冲突，当我最终将^/branches/B重新整合到^/branches/B时，仍应正确地提供工作的“责备”。
P.S。：这应该适用于svn＆lt; = 1.7，因为我们还不能切换到1.8。
更新
由于我不想从分支创建分支（trunk应该可以重新集成而不必等待A），我尝试了以下内容：
B然而，在这种情况下，即使自svn cp http://repo/trunk http://repo/branches/A
<... do some changes to A, commit to A>
svn cp http://repo/trunk http://repo/branches/B
svn co http://repo/branches/B
cd B
svn merge ^/branches/A
创建以来我在trunk或branches/B中没有更改任何内容，我也会遇到很多合并冲突。对此有何解释？
答案 0 :(得分：0)
如果功能B不依赖于功能A，那么我建议您根本不要将它们合并在一起。它们是独立的功能，因此您应该在其整个生命中独立对待它们，包括合并回主干。在最坏的情况下，功能B将在功能A合并到主干后立即获得功能A更改。
如果您的目标只是在一个版本中测试所有功能，那么我在这种情况下经常做的就是从trunk创建第三个“集成”分支。然后，我将两个功能分支的更改合并到此“集成”分支，但仅用于测试目的。一旦功能完全开发，我可以将每个功能独立地合并到主干，并丢弃我的集成分支。如果我感觉特别偏执，我可以将trunk与我的集成分支进行比较，以确保最终的合并符合我测试的结果。
如果功能B依赖于功能A来运行，那么我倾向于从功能A分支启动功能B分支，而不是从主干创建它。但是，这并非绝对必要。您应该能够将功能A合并到功能B中，并且由于SAME更改发生在每个分支上，任何合适的合并工具都不会有问题（除非您对该行进行进一步更改，我想）。如果该修订版的差异显示该行的更改，svn blame将仅记录一行中的更改。如果您的合并在合并之前留下一行，则blame不会更改为该行显示的修订版。
答案 1 :(得分：0)
好的，对我有用的答案如下：使用svn＆gt; = 1.8。
虽然在问题中特别要求svn 1.8无法使用，但最简单的答案仍然是使用它 - 但仅用于合并操作而不是其他任何内容。
这是有效的，因为所有需要做的就是检查要合并的分支的副本，进行合并，并将其与svn 1.8+客户端一起提交。之后，可以删除工作副本，并且可以像以前一样使用svn 1.7进行正常的工作流程。