在Subversion中阻塞文件夹
当你试图检查Subversion时，“阻塞”是什么意思？ 我看到两个红色文件夹的文本状态为“阻塞”。 我不明白这是什么意思在文档中的任何地方。
当我尝试cleanup命令，我得到“文件夹名称不是一个工作目录”。 这是我刚刚在VS中创build的文件夹，当我尝试将它添加到Subversion时，它给了我这个错误。 所有其他文件夹都很好。
它发生在删除或移动.svn子目录（不通过SVN命令）时，所以SVN的工作副本视图已损坏。
首先尝试清理，如果不能解决问题，请恢复（或更新）目录以恢复子目录.svn文件夹。
不知道是什么原因造成的，解决办法可以是将工作副本（本地的全部结账）导出到其他地方。
如果你正在使用tortoisesvn，你可以select“导出未版本化的文件”，但是我认为如果从命令行执行它，它只会导出版本化的文件，所以你可能有点费力地复制未版本化的文件。
一旦完成，检查出一个干净的工作副本，然后将导出的备份放在上面。 备份中没有.svn文件夹是非常重要的。
我以前看过这些错误的时候，人们已经在其他工作副本或其他任何破坏.svn条目的工作副本中检出了工作副本。
有同样的问题，并像这样修复它：
- 重新命名被阻止的目录
- 在SVN中创build了它的原始名称（例如svn mkdir）
- 更新父文件夹，所以新创build的目录出现在我的工作副本
- 将文件从阻塞的文件复制到新创build的目录并提交它们
如果您使用的是* nix系统，请确保您没有创build文件，将其添加到SVN，然后将其删除，并将其replace为相同名称的文件夹。 没有帮助OP，但希望它可以节省一些压力。
这意味着，由于某种原因，在手术过程中发生了冲突。 检查是否存在与版本化版本相同名称的现有未版本控制的文件或文件夹。
（从Tortoise SVN客户端帮助文件中解释）
没有为我工作，所以我做了以下几点：
- 导出与未版本的文件在一个新的位置
- 重命名现有的文件夹
- 从项目中的导出位置移动文件夹
- 重命名新的文件夹
- 添加，提交
- 删除旧的，重命名的文件夹
- 重命名新的文件夹
- 承诺
有不同的情况可能会导致这种情况。 这里是一个例子：
我结束了！ 在没有使用'svn rename'命令的情况下，在从www重命名为www_a的目录中标记：
- 重命名带有原始名称的当前目录，例如重命名为www_b
- 将www_a重命名为www
- 确保你在www目录里做'svn update'或'svn revert'
- 删除最新的www目录而不使用'svn delete'
- 转到父目录，并发出“svn update”
- 这将恢复原来的www目录
- 这次使用'svn rename'将www重命名为www_a
- 将www_b重命名为www
- 使用'svn add'将其添加到存储库中
此时你应该得到一个正确的svn工作目录。 并学习一两个如何解决svn目录混淆。
在Windows机器上面对这个问题。
在检查完属于它的整个项目之前，我已经检查了目录。 它给我造成了“阻碍”的问题。
我只是删除该文件夹，并从根目录（该文件夹）运行更新。 它工作正常。
像清理等命令没有为我工作。
谨慎的说一句话：
- 如果该文件夹很大，这是昂贵的。
- 如果有任何改变，会导致你失去所有的改变。
祝一切顺利。
当我创build了一个到版本库目录的符号链接时，我也在Windows上看到了这一点; 在这种情况下，存储库根目录被视为“阻塞”。 这似乎没有任何影响，但。
重现步骤：
-
检查你的回购
svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir -
检查你的目录是否正确
cd plugin_dir svn st -u输出应该是
Status against revision: 1234 -
创build符号链接（显示问题）
cd .. mklink /d link_dir plugin_dir cd link_dir svn st -u输出将是
~ 1234 . Status against revision: 1234
我遇到这个问题时，粘贴到我的FTP客户端的工作副本的子目录的文件夹 – 我知道我只要我点击转移button搞砸了…工作方式的危险太迟了。
我尝试了以上所有的build议和其他网上find的build议无济于事。 每个选项产生的错误，我的目录被locking，操作无法执行。
我进入了我的时间机器副本，恢复目录，并很好去。 为了预防，我清理了工作副本，正确更新了文件，并重新开始工作。
我们经常在旅途中有多个分支在同一时间，为了节省我切换或与IISconfiguration搞乱我检查每个分支到一个单独的文件夹。 然后，我使用目录链接将这些文件夹连接回在IIS中configuration的主path。
所以对于我来说，链接的目录总是有一个黄色的感叹号，并被标记为阻塞。 我相信这是因为它在技术上被创build/移出SVN之外。
当我通过Web界面更新到CMS（WordPress或Drupal）时，我在目录上遇到这种“阻塞”的状态 – 应用程序不知道它的代码实际上是一个颠覆的工作副本，所以当更新一个插件时，它将删除该插件的目录（包括.svn目录），并从插件的新版本中删除一个新的目录。
从包含阻止的目录的目录中获取该.svn目录。 我用--force结账。 例如，如果plugin_dir被标记为“〜”，则从其父目录运行：
svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
任何已经存在的文件都会被保留，并在结帐命令的输出中标记为“E”（当我运行svn status时，标记为“M”）。
我有时必须返回并添加更新中的新文件; 或者删除应该作为更新的一部分被删除的文件，因为他们在我结账时重新出现。 我相信这些在结帐时标记为“A”，但随后的svn status不会提及它们。
我在Eclipse中遇到了一些文件标有红色感叹号的文件。 问题是源目录中的一个杂散的.svn文件夹。 我删除了.svn文件夹，刷新了eclipse，并能够检查文件。
当您将Subversion升级到XCode不支持的版本时，也会发生这种情况。
这是我find解决这个问题最简单（也是最安全）的方法：
- 临时重命名受阻文件或目录（或父目录）（例如添加“.backup”）。
- 删除重命名目录内的任何
.svn目录（如果适用）。 -
svn revert从步骤1重命名（现在丢失）的对象。 -
svn delete已还原的对象。 - 将步骤1中的备份重新重命名为其原始名称。
- 将重命名的对象添加并签入svn作为新的对象。
当我用一个文件夹replace了一个具有完全相同名称的文件时，这种情况就发生了。 通过删除旧文件解决，提交，然后添加新的。 有点哈克，但为我工作:)
