我们最近创建了一个分支，其中包含为特定客户端定制的代码版本。我们同时在两个分支上工作，将“共同”更改提交到主干，然后将它们合并到分支。
最近，我们遇到了麻烦的情况。在trunk/bar.c中，我们（以及其他）具有foo()函数。现在，在branch/bar.c中删除了该函数，因为那里没有用它。在foo()中修改trunk时会出现问题。当我们将更改合并到分支（“合并范围的修订”）时，TortoiseSVN“3向合并”工具在方法上显示冲突（这很烦人，但我可以看到一些原因， ），但它也在文件中显示了一个完整的很多其他更改 - 这似乎是凭空出现（看起来有点像是否要显示之间所做的所有更改主干和分支）。这使得合并变得更加困难，因为它充斥着一些不重要和旧的变化。
这样的情况发生在你身上吗？您会建议什么，特别是在合并期间更容易发现重要差异？
作为（希望）临时解决方案，我将尝试#ifdef删除已删除的区域，以便SVN认为代码仍然存在并且有更好的合并时间。 （不幸的是，这将使代码变得有点丑陋，并且在删除更多函数时变得更加丑陋。）
答案 0 :(得分：1)
您可能需要考虑
听起来我觉得你的版本没有得到你想要的粒度;也就是说，一个修订包含许多变化。或者你正试图合并比你需要的更广泛的修订。无论如何，如果您经常提交，可能会有所帮助。
对于这种特殊情况，您必须手动合并文件 - 一旦这样做，您应该能够在不进行任何干预的情况下合并不涉及foo()的后续修订。
答案 1 :(得分：0)
好吧，我不是SVN专家，但我可以建议您从第一个分支的提交中导出补丁并将补丁应用到第二个分支。
我想这几乎就是Mercurial'hg transplant XXX'命令所做的。我不知道是否存在任何SVN等效命令。
答案 2 :(得分：0)
如果您更改了已在分支上删除的主干上的功能，则可能会发生冲突，这很自然。
是的，对于“右手边”，你会看到树干和树枝之间的所有变化。如果您考虑一下，这是唯一一组合理的变化。 （至少，服务器上的版本1.4就是这种情况;更好的合并跟踪的更高版本可能更简洁，但你需要有足够的客户端版本，我不确定。我真的需要升级......叹息。）但显示的分支更改应该全部被合并自动标记为未修改，除非它们与主干的更改冲突或以其他方式进行交互。
你永远不会对你看到的一系列变化感到惊讶。如果您是，那么您选择了错误的修订版，或者您误解了合并过程的工作原理。