Svn 是否已知服务器端文件夹重命名（移动）会在Subversion中创建损坏的工作副本？

我遇到过这样的情况：subversion客户端不会使用“svn更新”进行更新，用户必须擦除其工作副本并签出新副本，否则必须先恢复

为什么会发生这种情况？当发生这种情况时，所有本应处于清除/未修改状态的文件都显示为“已添加（+）”，即使用户没有添加它们？客户端人员没有采取任何措施使其工作副本变脏。在服务器端发生了更改，但在服务器端，可能有人将分支从

/branchs/featurebranch3/component/X

合并、提交，然后复制到

/trunk/component/X

未执行此合并的开发人员只有一个工作副本，并且每天都在尝试跟踪主干和更新，无法“更新”其工作副本，必须手动备份任何未提交的文件，然后要么销毁整个工作副本，要么执行

还原-R

，然后再次更新。发生这种情况的时间和原因，以及它与服务器端合并、移动和复制的关系如何？我知道这两者有关联，但我不明白到底发生了什么

如果没有人在服务器上移动、删除或复制文件夹，则此问题的发生率将降低

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

一组可以可靠地复制此类损坏工作副本的步骤：

创建一个文件夹

/branch/test1/components/component1

，进行一些合并，并工作到该分支中

删除现有文件夹

/trunk/components/component1

将文件夹

/branch/test1/components/component1

复制到

/trunk/components/component1

似乎恢复不足以解决此问题，每次在服务器上执行删除+复制操作时，都必须擦除工作副本并重新开始

在更新过程中，客户端上的消息有时没有错误，只是静默不做任何事情，有时TortoiseSVN在更新中说“跳过，没有版本化的父级”，而文件保持“正常（+）”状态。此工作副本无法更新或还原，并且处于“中间”状态

客户：1.8.5 SlikSvn或TortoiseSVN 1.8.5，构建25224

SVN服务器：1.8.8

服务器端合并（从技术上讲）是不存在的：合并总是发生在WC中，并作为提交的结果出现在存储库中

如果有人以无脑非主线的方式使用SVN，他将得到完全无脑的结果

---

若您的测试用例步骤2-3只是胡思乱想：来自分支的所有更改（默认情况下）都必须作为合并的结果出现在源节点中。如果您想将分支头完全转移到主干状态，并从分歧点覆盖thunk中的所有更改-使用

svn merge

和正确的

-接受
选项（可能“他们的完全”将是最安全的类型）
我想对这个问题给出我自己的答案，希望它能帮助人们

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

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

颠覆被完全破坏的唯一一致症状是乌龟体内成百上千的正常（+）状态指示器。“跳过的，无版本的父项”并不总是被发出，但当它被输出时，这也是一个好迹象，表明您也被屏蔽了

有些情况可以通过使用SVN开关，然后SVN恢复，然后SVN更新来解决，但许多情况无法解决

简言之：

不要这样做。不要替换对象。因为subversion无法处理它，也不会警告您，它只会中断所有用户并中断其所有工作副本

B.Subversion不是一个基于文件的版本控制系统（如git、mercurial和cvs），它是一个容器版本控制系统，它的容器看起来像文件夹，直到你真正尝试合并，然后它们才像你可能想象的那样。Subversion版本容器不仅包含您的文件，而且看起来很像文件夹，它们也是各种Subversion自己的版本控制元数据的元数据容器，有很多方法可以打破链，并使您的工作副本无形中被破坏。Git、Mercurial和CVS处理文件内容，这正是程序员所关心的。Subversion会对文件夹进行版本转换并创建“树冲突”，这对开发人员来说是没有用的，因为文件夹只是组织源代码的一种方式，并且（在git开发人员看来）不是模糊的不可见元数据的所有者。
Subversion甚至不能说出来并告诉你发生了什么，因为模型