我有两个从主干派生的特征分支，都涉及不同模块中的大代码重组，Feature-A和Feature-B。两者都与后备箱保持同步;行李箱必须稳定。
在使用Feature-B的过程中，我意识到最近在Feature-A上实现的对共享库的更改将极大地使Feature-B受益。我还不想把这个更改放在trunk中，我不能完全合并分支，因为Feature-A上的其余代码不稳定。
分支之间的合并，从A到B的挑选修订，只合并此功能：
svn merge -r 1786：1795 ^ / proj / branches / Feature-A。
我无法弄清楚以后当我重新整合分支时我是否会遇到麻烦。我希望Feature-B比Feature-A更快完成。此时我们的正常程序是将功能B重新集成到主干中，然后将主干合并到功能A中以保持同步。我很难提前搞清楚这是否会引起冲突，看到A被合并到B中，现在这些变化正在以迂回的方式重新合并，通过后备箱。
svn book提到，如果我希望能够再次在分支上工作，那么在将分支重新集成到主干之后，只能与--record合并。我怀疑在这种情况下我可能需要这样的东西，但如果有必要，我就无法解决。
答案 0 :(得分：0)
我个人不会将--reintegrate与长期功能分支一起使用。
在您的情况下，您可以将Feature-B分支合并回主干，然后，在将Feature-B合并回主干之前，对--record-only进行有问题的修订：
假设命令：
svn merge -r 1786:1795 ^/proj/branches/Feature-A .
创建了2000版本（在分支Feature-B中）。
然后，在将Feature-B合并回主干之前，您必须执行以下操作：
svn merge -c2000 --record-only ^/proj/branches/Feature-B .
最后一步是将Feature-B分支完全合并到trunk：
svn merge -r <begin>:<end> ^/proj/branches/Feature-B .
答案 1 :(得分：0)
这确实会给你带来麻烦。
如果从A到B合并的更改包含其他文件，那么当您重新集成B时，这些文件将添加到trunk。但是，如果您尝试从主干合并到A（在重新集成A之前需要执行此操作），则合并将尝试将这些文件重新添加到已存在于A中的A，从而导致树冲突。
A --record-only merge用于阻止特定修订的重新合并，以便在重新集成后保持功能分支处于活动状态。因此，如果您将B重新集成到创建修订版100的主干中，那么您 - 仅将主干修订版100合并回B，这意味着当您从主干（Svn merge ^ / Project1 / trunk）修订版100中执行B同步合并时将被跳过并且不会重新回到B.这样可以避免潜在的冲突并使功能分支继续使用，并在重新集成后重新使用主干。
不幸的是我不认为--record-only合并可以帮助你避免在你的情况下发生冲突，因为重新整合合并不检查要合并的分支中的各个修订，它只是做差异分支和主干的当前状态，并将其应用于主干工作副本。