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

时间：2014-03-21 18:13:08

标签： svn

enter image description here

我遇到的情况是subversion客户端不会使用＆＃34; svn update＆＃34;进行更新，用户必须擦除他们的工作副本并检查新的副本，否则像this question他们必须先恢复

为什么会这样？当它发生所有应该是干净/未修改状态的文件时，显示为＆＃34;添加（+）＆＃34;，即使用户没有添加它们？客户方人员没有做任何事情来使他的工作副本变脏。但是，在服务器端发生了更改，在服务器端，有人可能已合并，进行了评估，然后将分支从/branches/featurebranch3/component/X复制到/trunk/component/X。

没有这样做的开发者合并并且只有一个工作副本，并且每天都在尝试跟踪主干和更新，不能更新＆＃34;他的工作副本，必须手动备份任何未提交的文件，然后核对整个工作副本，或者执行revert -R然后再次更新。何时以及为什么会发生这种情况，它与服务器端合并，移动和复制有何关系？我知道这两者是相关的，但我不明白究竟发生了什么。

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

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

可以可靠地再现这种破碎的工作副本的一组步骤：

  1. 创建一个文件夹/branch/test1/components/component1，进行一些合并并在INTO这个分支中工作。

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

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

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

  5. 更新期间客户端上的消息有时没有错误，只是无声无效，有时TortoiseSVN说＆＃34;跳过，没有版本化的父母＆＃34;在更新中，文件保持状态＆＃34;正常（+）＆＃34;。此工作副本无法更新，也无法恢复，并且在“＃34”之间卡住了。

    6. 客户端：1.8.5 SlikSvn或TortoiseSVN 1.8.5，build 25224。

    SVNServer：1.8.8

2 个答案:

答案 0 :(得分：3)

我想对这个问题给出我自己的答案，希望能帮助别人。

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

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

  3. 完全破坏Subversion的唯一一致症状是TortoiseSVN中数百或数千个正常（+）状态指示符。 “跳过，没有版本化的父级”并不总是被发出，但是当它被输出时，这是一个很好的迹象，你也会被剔除。

  4. 有些情况可以使用SVN SWITCH然后使用SVN REVERT然后SVN更新，但很多情况不能。

    5. 简而言之：

    一个。不要这样做。不要更换物体。因为subversion无法处理它，也不会警告你，它只会打破所有用户并打破所有工作副本。

    B中。 Subversion不是基于文件的版本控制系统（如git，mercurial和cvs），它是一个容器版本控制系统，它的容器看起来像文件夹，直到你真正尝试合并，然后它们就像你可能想象的一样。 Subversion版本的容器不仅包含你的文件，而且看起来很像文件夹，它们也是各种subversion自己的版本控制元数据的元数据容器，有很多种方法可以打破链，并渲染你的工作副本无形中断了。 Git，Mercurial和CVS使用文件内容，这是程序员关心的。 Subversion版本文件夹并创建“树冲突”，这对开发人员没用，因为文件夹只是一种组织源代码的方式，而不是（对于git开发人员来说）隐藏不可见元数据的所有者。 Subversion甚至不能说出来并且告诉你是什么，因为模型是如此破碎，没有合理的错误信息用简单的英语可以很容易地告诉你如何解决它。

答案 1 :(得分：1)

  1. 服务器端合并（技术上）是不存在的东西：合并总是发生在WC中，并作为提交结果出现在存储库中
  2. 如果有人在无脑无主线方式使用SVN，他会得到如此完全无脑的结果

    3. 如果您的测试用例步骤2-3只是谵妄：来自分支的所有更改必须（默认情况下）作为合并结果出现在源节点中。如果你想转移到分支HEAD的主干完全状态并从分歧点覆盖thunk中的所有变化 - 使用svn merge和正确的--accept选项（可能是＆＃39;他们的全部＆＃39;将是最安全的类型）

相关问题
最新问题