Subversion 中受阻的文件夹

当您试图检入 Subversion 时，“阻碍”到底是什么意思？我看到两个红色的文件夹，文本状态为“受阻”我不知道这在文件里有什么意义。

当我尝试使用 cleanup命令时，我会得到“文件夹名称不是工作目录”这是我刚刚在 VS 中创建的一个文件夹，当我试图将它添加到 Subversion 时，它会给我一个错误。其他文件夹都没问题。

96018 次浏览
小开
最佳答案

当您删除或移动。SVN 子目录(不经过 SVN 命令) ，因此 SVN 的工作副本视图已损坏。

首先尝试清理，如果这解决不了问题，恢复(或更新)目录以恢复子目录。Svn 文件夹。

小开

这意味着，由于某种原因，在操作期间发生了冲突。检查是否存在与已版本化文件名相同的现有未版本化文件或文件夹。

(改述自 Tortoise SVN 客户端帮助文件)

小开

在不知道 什么导致这种情况的情况下，解决方案可能是将工作副本(本地的整个签出)导出到其他地方。

如果您使用 tortoisesvn，您可以选择“导出未版本化的文件”，但是我认为如果从命令行执行此操作，它只导出已版本化的文件，因此您可能需要手动复制未版本化的文件，这是一项有点费力的工作。

完成后，签出一个干净的工作副本，然后将导出的备份放在上面。非常重要的是，备份没有。中的 svn 文件夹。

我以前见过这些错误，当人们检出其他工作副本中的工作副本或其他任何损坏。Svn 条目。

小开

如果使用的是 * nix 系统，请确保没有创建文件，将其添加到 SVN，然后删除它，并用相同名称的文件夹替换它。没什么帮助，但希望能给某人省点压力。

小开

我遇到了这个问题，当粘贴在文件夹与子目录到我的工作副本使用我的 FTP 客户端-我知道我搞砸了，只要我按下传输按钮... 工作方式太晚的危险。

我尝试了以上所有的建议和网上找到的其他建议，但都无济于事。每个选项都会产生锁定目录和无法执行操作的错误。

我进入我的时间机器副本，恢复了目录，就可以开始了。作为预防措施，我清理了工作副本，正确地更新了我的文件，然后重新开始工作。

小开

遇到了同样的问题，就这样解决了:

  • 重新命名了受阻的目录
  • 在 SVN (例如 SVN mkdir)中使用原始名称创建 dir
  • 更新了父文件夹，这样新创建的目录就会出现在我的工作副本中
  • 将文件从阻塞目录复制到新创建的目录并提交它们
小开

对我来说没什么用，所以我做了以下几件事:

  • 在一个新的位置导出未版本化的文件
  • 重命名现有文件夹
  • 从项目中的导出位置移动文件夹
  • 重命名新文件夹
  • 加，承诺
  • 删除重命名的旧文件夹
  • 重命名新文件夹
  • 承诺
小开

我们经常在同一时间有多个分支，为了节省我切换或乱搞 IIS 配置，我将每个分支检出到一个单独的文件夹。然后使用目录链接将这些文件夹连接回 IIS 中配置的主路径。

因此，对我来说，链接目录总是有一个黄色的感叹号，并标记为阻塞。我相信这是因为它在技术上是在 SVN 之外创建/移动的。

小开

可能导致这种情况的情况有不同的变化。 这里有一个例子:

最后我得到了！在没有使用“ svn rename”命令的情况下，将目录从 www 重命名为 www _ a:

  1. 重新命名带有原名的工作目录，例如 www _ b
  2. 将 www _ a 重命名为 www
  3. 请确保在 www 目录中执行“ svn update”或“ svn return”
  4. 使用‘ svn Delete’删除最新的 www 目录 没有
  5. 转到父目录并发出‘ svn update’
  6. 这将恢复原来的 www 目录
  7. 这次使用“ svn rename”将 www 重命名为 www _ a
  8. 将 www _ b 重命名为 www
  9. 使用‘ svn add’将其添加到存储库中

此时您应该得到一个正确的 svn 工作目录。并学习一些关于如何解决 svn 目录混淆的知识。

小开

当我通过 web 界面对 CMS (WordPress 或 Drupal)进行更新时，我会在目录上看到这种“阻塞”状态——应用程序不知道它的代码实际上是一个颠覆工作副本，所以当更新插件时，它会删除该插件的目录(包括 .svn目录) ，并从新版本的插件中放入一个新的目录。

从包含阻塞目录的目录中返回该 .svn目录。我用 --force结账。例如，如果 plugin_dir标记为“ ~”，则从它的父目录运行:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

任何已经存在的文件都被单独留下，并在 checkout 命令的输出中标记为“ E”(当我运行 svn status时标记为“ M”)。

我有时不得不返回并添加更新中的新文件; 或者删除应该作为更新的一部分删除的文件，因为它们在我结帐时重新出现。我相信这些在结帐时被标记为“ A”，但随后的 svn status不会提到它们。

小开

我在 Eclipse 中遇到过这种情况，有些文件用红色叹号标记。问题出在一只流浪狗身上。源目录中的 svn 文件夹。我删除了。Svn 文件夹，刷新 Eclipse，并能够签入文件。

小开

当您将 subversion 升级到 XCode 不支持的版本时，也可能发生这种情况。

小开

在 Windows 机器上面临这个问题。

在我检查它所属的整个项目之前，我已经检查了这个目录。它给我造成了“障碍”问题。

我只是删除了那个文件夹，然后从根目录运行了一个更新。

清理等命令对我不起作用。

一些忠告:

  1. 如果文件夹较大，则开销较大。
  2. 如果有任何更改，它将导致您失去所有更改。

一切顺利。

小开

下面是我找到的解决这个问题的最简单(也是最安全)的方法:

  1. 暂时重命名阻塞的文件或目录(或父目录)(例如，添加“。备份”)。
  2. 删除重命名目录中的任何 .svn目录(如果适用)。
  3. svn revert步骤1中重命名(现在丢失)的对象。
  4. 返回的对象。
  5. 从步骤1将备份重命名为其原始名称。
  6. 将重命名的对象作为新对象添加并签入到 svn 中。
小开

当我用一个具有完全相同名称的文件夹替换一个文件时，我想到了这个问题。 通过删除旧文件、提交并添加新文件解决了这个问题。 有点粗俗，但对我有用:)

小开

在 Windows 中，当我创建一个指向存储库目录的符号链接时，我也看到过这种情况; 在这种情况下，存储库根目录被视为“受阻”。不过，这似乎没有任何影响。

复制步骤:

  1. 看看你的回购

    svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

  2. Check that your directory is OK

    cd plugin_dir
svn st -u

    输出应该是

    Status against revision: 1234

  3. Create the symlink (which shows the problem) 

    cd ..
mklink /d link_dir plugin_dir
cd link_dir
svn st -u

    输出将是

    ~           1234  .
Status against revision: 1234

提交答案