Subversion中的文件夹受阻

当您尝试签入Subversion时，“阻塞”到底意味着什么？我看到两个文件夹为红色，文本状态为“阻塞”。我在文档中的任何地方都看不到这意味着什么。

当我尝试该cleanup命令时，出现“文件夹名称不是工作目录”。这是我在VS中刚刚创建的文件夹，当我尝试将其添加到Subversion时，出现了该错误。所有其他文件夹都可以。

当您删除或移动了.svn子目录（不通过SVN命令）时，就会发生这种情况，因此SVN的工作副本视图已损坏。

首先尝试清理，如果仍然不能解决，请还原（或更新）目录以还原子目录.svn文件夹。

不知道是什么原因造成的，解决方案可能是将工作副本（您在本地拥有的整个结帐）导出到其他地方。

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

完成后，签出干净的工作副本，然后将导出的备份放在其顶部。备份中没有.svn文件夹，这一点非常重要。

在人们检出其他工作副本中的工作副本或任何损坏.svn条目的东西之前，我已经看到这些错误。

遇到了相同的问题，并按以下方式修复了它：

• 重命名了受阻目录
• 使用SVN中的原始名称创建了目录（例如svn mkdir）
• 更新了父文件夹，因此新创建的目录出现在我的工作副本中
• 将文件从受阻文件复制到新创建的目录并提交

如果您使用的是* nix系统，请确保未创建文件，将其添加到SVN，然后将其删除，并用相同名称的文件夹替换。对OP没有帮助，但希望它可以减轻某人的压力。

这意味着，由于某种原因，在操作过程中发生了冲突。检查是否存在现有的未版本控制的文件或文件夹，其名称与版本相同。

（摘自Tortoise SVN客户端帮助文件）

没有任何帮助，所以我做了以下工作：

• 将未版本控制的文件导出到新位置
• 重命名现有文件夹
• 将文件夹从项目中的导出位置移出
• 重命名了新文件夹
• 添加，提交
• 删除了旧的，已重命名的文件夹
• 重命名了新文件夹
• 承诺

场景的不同变化都可能导致这种情况。这是一个例子：

我最终以！在从www重命名为www_a的目录上标记而不使用'svnname'命令：

1. 重命名具有原始名称的当前目录，例如，更改为www_b
2. 将www_a重命名为www
3. 确保在www目录中执行“ svn更新”或“ svn恢复”
4. 删除最新的www目录，而无需使用'svn delete'
5. 转到父目录并发出“ svn更新”
6. 这将还原原始的www目录
7. 这次使用“ svn重命名”将www重命名为www_a
8. 将www_b重命名为www
9. 使用'svn add'将其添加到存储库中

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

在Windows计算机上面临此问题。

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

我只是删除了该文件夹，然后从该文件夹的根目录运行了更新。工作正常。

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

请注意：

1. 如果文件夹很大，这会很昂贵。
2. 如果有更改，它将导致您丢失所有更改。

祝一切顺利。

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

重现步骤：

1. 签出您的仓库

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

2. 检查您的目录是否正确

   cd plugin_dir
   svn st -u
   

   输出应为

   Status against revision: 1234
   

3. 创建符号链接（显示问题）

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

   输出将是

   ~           1234  .
   Status against revision: 1234
   

当我使用FTP客户端将带有子目录的文件夹粘贴到工作副本中时遇到了这个问题-我知道我一按下传输按钮就搞砸了，工作的危险已经来不及了。

我尝试了上述所有建议，但在网上发现其他建议均无济于事。每个选项均产生以下错误：我的目录已锁定，无法执行该操作。

我进入了Time Machine副本，恢复了目录，一切顺利。作为预防措施，我清理了工作副本，正确更新了文件，然后恢复了正常工作。

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

因此，对我而言，链接目录始终带有黄色感叹号，并标记为受阻。我相信这是因为它在技术上是在SVN之外创建/移动的。

当我通过Web界面更新CMS（WordPress或Drupal）时，我在目录上得到此“受阻”状态-应用程序不知道其代码实际上是Subversion工作副本，因此在更新插件时会删除该插件的目录（包括.svn目录），并从新版本的插件中放入新目录。

要从.svn包含受阻目录的目录中获取该目录。我通过结帐--force。例如，如果plugin_dir标记为“〜”，则从其父目录运行：

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

已经存在的所有文件都保留下来，并在checkout命令的输出上标记为“ E”（在我运行时标记为“ M” svn status）。

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

我在Eclipse中遇到了这个问题，在该文件中，某些文件带有红色感叹号。问题是源目录中有一个.svn文件夹。我删除了.svn文件夹，刷新了Eclipse，并且能够检入文件。

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

这是我发现的最简单（最安全）的解决方法：

1. 临时重命名被阻塞的有问题的文件或目录（或父目录）（例如，添加“ .backup”）。
2. 删除任何 .svn重命名目录内的所有目录（如果适用）。
3. svn revert 步骤1中重命名（现在丢失）的对象。
4. svn delete 还原的对象。
5. 将步骤1中的备份重命名为其原始名称。
6. 将重命名的对象作为新对象添加并签入到svn中。

当我用完全相同的名称的文件夹替换文件时，这发生在我身上。通过删除旧文件来解决，提交，然后添加新文件。有点hacky，但为我工作:)

我在受阻目录中删除了.svn并从外部对其进行了更新。然后，外部svn命令将识别这些文件。