Svn 尝试撤消Subversion中的更改时发生冲突示例

在探索Subversion中的功能时，我试图测试在本教程的分支和合并一章的基本合并部分的撤消更改小节中描述的用例。我使用的是1.6.4版，但该部分的文本在本书的两个版本中都是相同的

在我的工作副本目录中，我编辑一个文件testcode.py，每次编辑添加一行，每次编辑后提交。在多次提交后，文件的内容如下：

this is my first import to trunk.  r1.

this is my first commit, first edit of testcode.py.  r2.

this is another edit of testcode.py.  r3.

this is an edit of testcode.py.  i'll get rid of this one.  r4.

this is another edit of testcode.py.  keeping it.  r5.

yet another edit.  keeping it.  r6.

存储库中的修订号与文件中的行匹配，例如在/trunk/testcode中。py@rN，文件的最后一行是以rN结尾的行。我要做的是删除以r4结尾的行，保持之前和之后的所有内容不变

按照svnbook的undoingchanges部分中的示例，我运行命令

svn merge -c -4 file:///path_to_repos/trunk

这会产生冲突（在运行该命令时，而不是在提交时），合并左文件包含直到第r4行的所有内容，合并右文件包含直到第r3行的所有内容。换句话说，该命令似乎希望将整个文件恢复到版本3或版本4，而不是删除过去的更改，从而删除后续版本中的更改（本例中为5和6）

按照我在svnbook中阅读示例的方式，用户撤销了在修订版303中提交的更改，并将结果提交到修订版350，没有冲突，我运行的命令应该生成一个svn状态为M的文件，该文件保留了除以r4结尾的行之外的所有行

---

我是否错误地阅读了本书的示例，示例是否错误，或者是否有其他形式的用户错误是我无意中遇到的？

基本问题是Subversion的diff算法以一种不一定直观的方式处理文件开头和结尾处的更改。您的示例正好符合这种情况，而野外的大多数更改都不符合这种情况。考虑在一系列提交之后看起来像这样的文件：

later commit (r5)
change to be reverted at beginning of file (r2)
initial commit (r1)
change to be reverted in middle of file (r3)
initial commit (r1)
change to be reverted at end of file (r4)
later commit (r5)

尝试将提交还原到文件的开头或结尾（示例中的修订版2和4）会产生冲突。将更改恢复到文件的中间位置可以正常工作

从概念上讲，将变更集视为具有受周围行限制的范围可能会有所帮助。对文件中间的更改以周围未更改的线为边界。文件开头或结尾处的更改范围一直延伸到文件开头或结尾，无论该点随后移动了多远

因此，在上面的示例中，修订5中添加的第二行正好在修订4的范围内。以同样的方式，您预期冲突会在这里重新修订10，因为修订11中的更改在其中间是SAMAK DAB：

...                    <-- Line unchanged by revision 10, bounding its scope
line from revision 10  <--\
line from revision 11     | Revision 10's scope
line from revision 10  <--/
...                    <-- Line unchanged by revision 10, bounding its scope

---

。。。绝对可以复制。现在需要考虑为什么会发生这种情况。使用
svn diff-c-4 foo.txt>foo.patch
创建一个补丁，然后将其应用到
foo。txt@HEAD
按预期工作-删除r4行。因此修补程序可以工作，但“svn合并的一个非常常见的用例”，正如svn手册所说，这是一个简单的用例，有自己的小节，只是普通人没有。这并不能激发人们对Subversion合并功能在更复杂的过程（如重新整合分支）中的行为的信心。SVN合并在身体的所有主要部位都是一件痛苦的事情——与SVN一起工作的每个人都知道这一点。我没有足够的时间来检查在这种情况下发生了什么，但这是出乎意料的。我的直觉是，它与文件结尾所做的更改有关，但同样，我还没有检查过它。好吧，只要检查在文件中间添加的行会发生什么，而不是在结尾。工作良好-无冲突。非常有趣，100%可复制。谢谢你是通过实验发现的，你写了diff算法，还是在某处有记录？我可能会考虑在我的文件开始时，特别是现在，在文件的结尾处，放一个“虚拟”行。这是我的经验。事实上，我很难在这个答案中包含文档，但找不到任何内容？变更集的第一行（最靠近顶部）和最后一行（最靠近底部）定义了其“范围”。如果更改的第一行是文件中的第一行（或最后一行），则范围将“永远”扩展到顶部/底部。并且：如果在后续提交中更改了该更改集范围内的任何内容，则无法在不产生冲突的情况下反转原始更改集。对还是错？：）如果更改集完全由相邻行组成，则为True。如果在一个文件中的多个点上更改片段，则会得到多个作用域，而不是从第一个更改行到最后一个更改行的一个大作用域。
...                    <-- Line unchanged by revision 10, bounding its scope
line from revision 10  <--\
line from revision 11     | Revision 10's scope
<EOF>                  <--/ (No unchanged line bounding the scope this direction)