svn - 服务器端文件夹重命名(移动)是否会在 Subversion 中创建损坏的工作副本？

Question

我遇到了 Subversion 客户端无法使用“svn update”进行更新的情况，用户必须删除其工作副本并查看新的副本，或者像 this question他们必须首先恢复。

为什么会发生这种情况？当这种情况发生时，所有应该处于干净/未修改状态的文件都显示为“已添加(+)”，即使用户没有添加它们？客户端人员没有做任何事情来弄脏他的工作副本。服务器端发生了更改，但是在服务器端，有人可能合并、提交，然后将分支从 /branches/featurebranch3/component/X 复制到 /trunk/component/X。

没有进行此合并并且仅拥有工作副本并尝试每天跟踪主干和更新的开发人员，无法“更新”他的工作副本，并且必须手动备份任何未提交的文件，然后要么破坏整个文件工作副本，或执行 revert -R 然后再次更新。何时、为何发生这种情况，它与服务器端合并、移动和复制有何关系？我知道两者是相关的，但我不明白到底发生了什么。

如果没有人在服务器上移动、删除或复制文件夹，那么此问题的发生率就会减少。

我怀疑服务器端重命名/移动可能会造成混合修订情况，但我不知道如何。

一组可以可靠地重现这种损坏的工作副本的步骤:

1. 创建一个文件夹 /branch/test1/components/component1，进行一些合并并进入此分支。

2. 删除现有文件夹/trunk/components/component1

3. 将文件夹 /branch/test1/components/component1 复制到 /trunk/components/component1

4. 恢复似乎不足以解决此问题，每次在服务器上完成此类删除+复制时，都必须删除工作副本并重新开始。

5. 更新期间客户端上的消息有时没有错误，只是静默不执行任何操作，有时 TortoiseSVN 在更新中显示“已跳过，无版本控制的父级”，而文件仍保持状态“正常(+)”。该工作副本无法更新，也无法恢复，并且卡在“中间”。

客户端:1.8.5 SlikSvn 或 TortoiseSVN 1.8.5，内部版本 25224。

SVN服务器:1.8.8

Answer 1

我想对这个问题给出自己的答案，希望对大家有所帮助。

1. 当您用其他新对象替换文件夹对象并替换先前的对象时，似乎没有链接这两个文件夹对象的修订图信息。因此，无法跟踪和更新基于先前工作文件夹的工作副本。

2. 虽然“C:\Folder1\Folder2\Folder3”对您来说是同一个对象，但在 Subversion 的术语中它不是同一个对象。 Subversion 的工作是将对象存储在其数据库(客户端上的 SQLITE，或服务器上的 FSFS 存储)中，这些对象可以具有无限多个具有相同确切名称的对象，甚至在 YOUR 中具有相同的确切文件夹或有效的完全限定路径名。工作副本，但是，它永远不会将第一个文件夹 3 与第二个文件夹 3 等同起来。这是这个有意决定的结果(允许存储文件夹并使它们成为 SVN 系统中的第一类实体，而不是源代码文件的内容，可能编码为 DIFF 文件，正如您在 CVS 和 Mercurial 中看到的那样) ，它根本不跟踪文件夹，并且不能生成同等损坏的工作副本)，这会导致工作副本实际上变得无效并且不再可更新，这是我上面描述的问题的根源。

3. Subversion 完全损坏的唯一一致症状是 TortoiseSVN 中数百或数千个正常(+) 状态指示器。 “跳过，无版本控制的父级”并不总是被发出，但当它被输出时，这是一个好兆头，你也很无聊。

4. 某些情况可以通过使用 SVN SWITCH、SVN REVERT、SVN UPDATE 来解决，但许多情况则不能。

简而言之:

A.不要这样做。不要更换物体。因为 subversion 无法处理它，也不会警告你，它只会破坏所有用户并破坏他们的所有工作副本。

B. Subversion 不是一个基于文件的版本控制系统(如 git、mercurial 和 cvs)，它是一个容器版本控制系统，它的容器看起来像文件夹，直到您真正尝试合并，然后它们就不再像您想象的那样。 Subversion 版本容器不仅包含您的文件，而且看起来很像文件夹，它们也是各种 Subversion 自己的版本控制元数据的元数据容器，并且有很多方法可以打破链条，并呈现您的版本。工作副本无形地损坏了。 Git、Mercurial 和 CVS 处理文件内容，这是程序员关心的。 Subversion 版本文件夹并创建“树冲突”，这对开发人员没有用处，因为文件夹只是组织源代码的一种方式，并且(在 git 开发人员看来)不是模糊的不可见元数据的所有者。Subversion 甚至无法大声告诉你发生了什么事，因为模型已经损坏了，没有任何简单的英语错误消息可以让你很容易地知道如何修复它。