0

我们有一个相当典型的 SVN 存储库设置，其中^/trunk包含我们软件的当前稳定版本，并且在位于^/branches/<feature>. 分支与主干保持同步，一旦分支功能完整，它必须通过一系列测试才能重新集成到^/trunk.

然而，有时，我已经完成了一个功能，^/branches/A并希望在它自己的分支中处理^/branches/B（取决于A^/branches/A）中的另一个功能，然后才能将分支重新集成到^/trunk. 从一个分支到另一个分支获取特性的最佳实践是什么，而不是不必要地“破坏”历史？

只是为了澄清我对“break”的意思：我的目标是，当^/branches/A最终重新整合到时^/trunk，并且我从trunkto合并时^/branches/B，它不应该产生任何冲突，并且当我仍然应该正确贡献工作的“责备”时最后重新^/branches/B融入trunk也一样。

PS：这应该适用于 svn <= 1.7，因为我们还不能切换到 1.8。

更新

由于我不想从分支创建分支（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在创建branches/A. 对此有何解释？

4

2 回答 2

0

OK, the answer that works for me is the following: use svn >= 1.8.

Although it was asked specifically in the question that svn 1.8 cannot be used, the simplest answer is still to use it anyways - but just for the merge operation and nothing else.

This works because all that needs to be done is checking out a copy of the branch to merge to, doing the merge, and committing it with a svn 1.8+ client. Afterwards, the working copy can be deleted and svn 1.7 can be used as before for the normal workflow.

于 2013-09-10T11:52:45.847 回答
0

如果功能 B 不依赖于功能 A 来运行，那么我建议您根本不要费心将它们合并在一起。它们是独立的特性，因此您应该在它们的整个生命周期中独立对待它们，包括合并回主干。在最坏的情况下，功能 B 将在功能 A 合并到主干后立即获得功能 A 的更改。

如果您的目标只是在一个构建中测试所有功能，那么在这种情况下我经常做的是从主干创建第三个“集成”分支。然后，我将两个功能分支的更改合并到这个“集成”分支，但仅用于测试目的。功能完全开发后，我可以将每个功能独立合并回主干并丢弃我的集成分支。如果我感觉特别偏执，我可以将主干与我的集成分支进行比较，以确保最终的合并与我测试的结果相匹配。

如果功能 B 确实依赖于功能 A 来运行，那么我倾向于从功能 A 分支启动功能 B 分支，而不是从主干创建它。但是，这并不是绝对必要的。您应该能够将功能 A 合并到功能 B 中，并且由于每个分支上都发生了相同的更改，因此任何有价值的合并工具都不会有问题（除非您对该行进行进一步更改，我想）。并且svn blame仅当该修订的差异显示该行发生更改时才会注意到该行的更改。如果您的合并保留了合并之前的行，则责备不会更改为该行显示的修订。

于 2013-09-08T19:21:40.670 回答