合并到分支时发生冲突，删除代码中的一些更改
我们最近创建了一个分支，其中包含为特定客户定制的代码版本。我们同时在两个分支上工作，将“常见”更改提交到主干中，然后将它们合并到分支中。
最近，我们遇到了麻烦的情况。在 trunk/bar.c 中，我们（除其他外）有一个 foo() 函数。现在，在 branch/bar.c 中，该函数已被删除，因为它在那里没有用处。在 trunk 中修改 foo() 时会出现问题。当我们将更改合并到分支（“合并修订范围”）时，TortoiseSVN“3向合并”工具显示方法上的冲突（这很烦人，但我可以看到一些原因） ），但它也显示了文件中的许多其他更改 - 这似乎是凭空出现的（看起来有点像它想显示之间所做的所有更改树干和树枝）。这使得合并变得更加困难，因为它散布着一些不重要和旧的变化。
你有遇到过这样的情况吗？您有什么建议，特别是为了在合并过程中更容易发现重要差异？
作为（希望）临时解决方案，我将尝试使用 #ifdef 删除已删除的区域，以便 SVN 认为代码仍然存在，并且可以更好地进行合并。 （不幸的是，这会使代码变得有点难看，并且当删除更多函数时会变得更难看。）
We've recently created a branch with a version of code customized for a certain client. We're working on both branches at the same time, commiting 'common' changes into the trunk, then merging them to the branch.
Recently, we've come to a troublesome situation. In trunk/bar.c we have (among others) a foo() function. Now, in branch/bar.c the function was removed, as there's no use for it there. The problems occur when foo() is modified in the trunk. When we merge the changes into the branch ("Merge range of revisions"), TortoiseSVN "3-way merge" tool shows a conflict on the method (that is annoying but I can see some reasons in that), but it does also show a whole lot of other changes in the file - which seem to appear out of thin air (looks a bit like if it wanted to show all changes made between the trunk and the branch). And that makes merging much more difficult, as it is littered with some unimportant and old changes.
Did situations like that occur to you? What would you suggest, especially to make spotting important differences easier during merge?
As a (hopefully) temporary resolution I'm going to try and #ifdef out the removed regions, so that SVN would think the code is still there and have better time with merging. (Unfortunately, that's going to make the code a bit ugly, and getting uglier when more functions are removed.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能需要考虑
在我看来，您的修订并没有达到您想要的粒度；也就是说，一次修订包含多项变化。要么是这样，要么您正在尝试合并比您需要的更广泛的修订。无论如何，如果你更频繁地承诺，可能会有所帮助。
对于这种特殊情况，您必须手动合并文件 - 一旦这样做，您应该能够合并不涉及
foo()的后续修订，而无需任何干预。You may want to consider
It sounds to me like you aren’t getting quite the granularity that you want with your revisions; that is to say, one revision encompasses many changes. Either that or you’re trying to merge a wider range of revisions than you need. In any case, it may help if you commit more often.
For this particular case, you’ll have to merge the files manually — once you do, you should be able to merge subsequent revisions that don’t involve
foo()without any intervention.好吧，我不是 SVN 专家，但我可以建议您从第一个分支的提交中导出补丁并将补丁应用到第二个分支中。
我想这几乎就是 Mercurial 'hg port XXX' 命令的作用。不过，我不知道是否存在任何 SVN 等效命令。
Well, I'm not a SVN expert, but I can suggest you is to export a patch from a commit of your first branch and to apply the patch into the second branch.
I guess this is almost what the Mercurial 'hg transplant XXX' command does. I don't know if any SVN equivalent command exists, though.
如果您更改了已在分支上删除的主干上的功能，则可能会发生冲突，这是很自然的。
是的，对于“右侧”，您将看到主干和分支之间的所有变化。如果你仔细想想，这是唯一一组符合逻辑的变化。 （至少，服务器上的 1.4 版本就是这种情况；具有更好合并跟踪的更高版本可能会更简洁，但是您需要有足够的客户端版本，我不确定。我真的需要升级...叹息。）但是显示的分支更改应该全部自动标记为合并未修改，除非它们与主干的更改冲突或以其他方式交互。
您永远不应该对您看到的一系列变化感到惊讶。如果是，那么您要么选择了错误的修订版，要么误解了合并过程的工作原理。
If you change a function on the trunk that you have deleted on the branch, you can expect a conflict, this is natural.
And yes, for the "right-hand-side", you will see all the changes between the trunk and branch. If you think about it, this is the only set of changes that it is logical to show. (At least, that is the case with version 1.4 on the server; later versions with better merge tracking may possibly be able to be more concise, but you would need to have a sufficient client version, I'm not sure. I really need to upgrade ... sigh.) But the branch changes shown should all be automatically marked as unmodified by the merge, unless they conflict or otherwise interact with changes from the trunk.
You should never be surprised by the set of changes you see. If you are, then you have either selected the wrong revisions or you are misunderstanding something about how the merge process works.