【问题标题】:Obstructed folders in SubversionSubversion 中的受阻文件夹
【发布时间】:2009-05-20 21:49:53
【问题描述】:

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

当我尝试cleanup 命令时,我得到“文件夹名称不是工作目录”。这是我刚刚在 VS 中创建的一个文件夹,当我尝试将它添加到 Subversion 时,它给了我这个错误。所有其他文件夹都很好。

【问题讨论】:

  • 您在添加操作时遇到“阻塞”?

标签: svn


【解决方案1】:

当您删除或移动了 .svn 子目录时会发生这种情况(无需通过 SVN 命令),因此 SVN 的工作副本视图已损坏。

先尝试清理,如果不能解决问题,请恢复(或更新)目录以恢复子目录 .svn 文件夹。

【讨论】:

  • 很奇怪。我最终不得不签出这个文件夹。该文件夹以前存在于存储库中。然后我在不使用 svn delete 命令的情况下删除了它。通过检查它并提交,问题解决了。然后在另一个我没有重命名、删除并且只是编辑它的 .css 文件上,我不得不进行 svn 更新,因为我遇到了一些奇怪的问题(不同的消息)。
  • 天哪,我试图根据我在外部驱动器上的这个项目的副本提交,而不是我本地驱动器上的工作副本。呵呵。
  • 如果您将目录从一个地方移动到另一个地方并且不使用 SVN 移动命令,通常会发生这种情况。隐藏的 .svn 文件会随之移动,但不会更新。删除 .svn 文件可以解决问题。
  • 当我通过使用 Visual Studio 2008 将文件夹复制到另一个文件夹而不是使用 Windows 资源管理器来移动整个文件夹时,发生了这种情况。
  • 我解决的方法是从受阻文件夹中导出我的文件,这样我就不会丢失它们,然后我单击受阻文件夹上方的文件夹,单击还原,然后取消选择所有内容,但受阻文件夹,并恢复该受阻文件夹,因此它会将该文件夹从 .svn 文件的内容中提取出来。然后我用导出的文件重新添加了以前被阻塞的文件夹,并重新添加了它们。
【解决方案2】:

在不知道是什么导致这种情况的情况下,解决方案可以是将工作副本(您在本地拥有的整个结帐)导出到其他地方。

如果您使用的是 tortoisesvn,则可以选择“导出未版本控制的文件”,但我认为如果从命令行执行此操作,它只会导出版本控制文件,因此您可能需要执行一些费力的任务来复制 un-手动版本化文件。

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

当人们在其他工作副本或其他任何破坏 .svn 条目的内容中签出工作副本时,我已经看到过这些错误。

【讨论】:

  • 为我解决了这个问题。谢谢!
  • 我认为解决方案是将 SVN 放入垃圾箱并切换到不垃圾的版本控制系统。抱歉...我只是很沮丧。
【解决方案3】:

遇到了同样的问题并像这样修复它:

  • 重命名受阻目录
  • 在 SVN 中使用其原始名称创建目录(例如 svn mkdir)
  • 更新了父文件夹,所以新创建的目录出现在我的工作副本中
  • 将文件从阻塞复制到新创建的目录并提交

【讨论】:

  • 我遇到了问题的变体,但这为我指明了解决问题的正确方向。 SVN 链接文件或文件夹 NAME 发生的任何问题,因此该名称变得“受阻” - 并且仍然如此。因此,即使创建了具有相同名称的新文件或文件夹,它也会自动被阻止。使用 SVN 重命名文件或文件夹会将“障碍”更改为新名称,并且旧名称变得干净且再次可用。
【解决方案4】:

如果您在 *nix 系统上,请确保您没有创建文件,将其添加到 SVN,然后将其删除,将其替换为同名文件夹。对 OP 没有帮助,但希望它能减轻一些人的压力。

【讨论】:

    【解决方案5】:

    这意味着,由于某种原因,在操作过程中发生了冲突。检查是否存在与版本化文件同名的未版本化文件或文件夹。

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

    【讨论】:

      【解决方案6】:

      没有什么对我有用,所以我做了以下事情:

      • 与未版本化的文件一起导出到新位置
      • 重命名现有文件夹
      • 从项目中的导出位置移动文件夹
      • 重命名新文件夹
      • 添加,提交
      • 删除了旧的重命名文件夹
      • 重命名新文件夹
      • 提交

      【讨论】:

        【解决方案7】:

        可能导致这种情况的场景有多种变化。 这是一个例子:

        我最终得到了 !在没有使用 'svn rename' 命令的情况下从 www 重命名为 www_a 的目录上标记:

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

        此时你应该得到一个正确的 svn 工作目录。并学习一两件事如何解决 svn 目录混乱。

        【讨论】:

          【解决方案8】:

          在 Windows 机器上遇到此问题。

          我在检查它所属的整个项目之前检查了该目录。它给我造成了“阻塞”问题。

          我只是删除了该文件夹并从(该文件夹的)根目录运行更新。效果很好。

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

          请注意:

          1. 如果文件夹很大,成本会很高。
          2. 如果有任何更改,这将导致您丢失所有更改。

          一切顺利。

          【讨论】:

            【解决方案9】:

            当我创建到存储库目录的符号链接时,我也在 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
              

            【讨论】:

              【解决方案10】:

              我在使用我的 FTP 客户端将带有子目录的文件夹粘贴到我的工作副本时遇到了这个问题 - 我知道我一按下传输按钮就搞砸了……工作太晚的危险。

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

              我进入了我的 Time Machine 副本,恢复了目录,一切顺利。作为预防措施,我清理了工作副本,正确更新了我的文件并恢复了业务。

              【讨论】:

                【解决方案11】:

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

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

                【讨论】:

                  【解决方案12】:

                  当我通过 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 不会提及它们。

                  【讨论】:

                    【解决方案13】:

                    我在 Eclipse 中遇到了这个问题,其中一些文件标有红色感叹号。问题是源目录中有一个杂散的 .svn 文件夹。我删除了 .svn 文件夹,刷新了 eclipse,并且能够签入文件。

                    【讨论】:

                    • 是的,我不得不删除我的文件夹,它已损坏....svn 文件夹。
                    【解决方案14】:

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

                    【讨论】:

                      【解决方案15】:

                      这是我发现解决此问题的最简单(也是最安全)的方法:

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

                      【讨论】:

                        【解决方案16】:

                        当我用同名的文件夹替换文件时,我发生了这种情况。 通过删除旧文件,提交,然后添加新文件来解决。 有点hacky,但对我有用:)

                        【讨论】:

                          【解决方案17】:

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

                          【讨论】:

                            猜你喜欢
                            • 2011-09-10
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            • 1970-01-01
                            • 2011-12-23
                            • 1970-01-01
                            • 1970-01-01
                            相关资源
                            最近更新 更多