svn - 在 Subversion 中尝试撤消更改示例时发生冲突

Question

在探索 Subversion 中的功能时，我尝试测试 中描述的用例。撤消更改 svnbook 的分支和合并章节的基本合并部分的小节.我使用的是 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 的 Undoing Changes 部分中的示例，我运行命令

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

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

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

我是否错误地阅读了这本书的示例，示例是否错误，或者是否有其他形式的用户错误是我不知道的？

Answer 1

基本问题是 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 中的更改位于其中:

...                    <-- 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

出于同样的原因，您应该会在这里发生冲突:

...                    <-- 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)

请注意，这只是对为什么文件的开头和结尾似乎被区别对待的概念性解释，而不是理解 Subversion 合并过程的全面解释。