blocks|key|1552555|text|当您删除或移动了SVN子目录(没有执行.svn命令)时，就会发生这种情况，因此SVN子目录的工作副本视图已损坏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1552556|首先尝试清理，如果不能解决问题，则还原(或更新)目录以还原子目录.svn文件夹。|1552557|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

it occurs when you have deleted or moved the .svn subdirectories (without going through SVN commands), so SVN has a corrupted view of the working copy. 

Try a cleanup first, and if that doesn't solve it, revert (or update) the directory to restore the subdirectory .svn folders.

blocks|key|1337051|text|如果您使用的是*nix系统，请确保您没有创建文件，将其添加到SVN中，然后将其删除，并将其替换为同名的文件夹。对行动没什么帮助，但希望能减轻一些人的压力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1337052|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you're on a *nix system, ensure that you didn't create a file, add it to SVN, then delete it, replacing it with a folder of the same name. Doesn't help OP, but hopefully it'll save someone a bunch of stress.

blocks|key|1337013|text|这意味着，由于某种原因，在操作过程中发生了冲突。检查是否存在与版本化文件或文件夹同名的现有未版本化文件或文件夹。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1337014|(转译自Tortoise+SVN客户端帮助文件)|1337015|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This means that, for some reason, a conflict has occurred during the operation. Check to see if there is an existing unversioned file or folder with the same name as a versioned one.

(Paraphrased from the Tortoise SVN client help file)

blocks|key|1552676|text|当我使用FTP客户端将带有子目录的文件夹粘贴到我的工作副本中时，我遇到了这个问题-我知道我一按下transfer按钮就搞砸了……工作方式太晚的危险。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1552677|我尝试了上面所有的建议和其他在网上找到的建议，但都没有用。每个选项都会产生错误，即我的目录已锁定，无法执行操作。|1552678|我进入我的Time+Machine副本，恢复了目录，可以正常运行了。我清理了工作副本作为预防措施，适当地更新了我的文件，并恢复了业务。|1552679|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I ran into this problem when pasting at folder with subdirectories into my working copy using my FTP client - I knew I screwed up as soon as I hit the transfer button... the perils of working way too late.

I tried all the suggestions above and other found online to no avail. Every option produced the error that my directory was locked and the operation could not be performed.

I went into my Time Machine copy, restored the directory and was good to go. I cleaned the working copy as a precaution, updated my files properly and was back in business.

blocks|key|1337136|text|我们通常同时有多个分支，为了省去切换或处理IIS配置的麻烦，我会将每个分支签出到一个单独的文件夹中。然后，我使用目录链接将这些文件夹连接回在IIS中配置的主路径。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1337137|因此，对我来说，链接的目录总是有一个黄色的感叹号，并被标记为受阻。我相信这是因为它在技术上是在SVN之外创建/移动的。|1337138|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We often have multiple branches on the go at the same time, in order to save me switching or messing around with IIS configuration I check each branch out to a separate folder. I then use directory linking to connect those folders back to the main path configured in IIS. 

So for me the linked directory always has a yellow exclamation and is marked as obstructed. I believe this is because it was technically created/moved outside of SVN.

blocks|key|1337169|text|当我通过web界面对一个内容管理系统(WordPress或Drupal)进行更新时，我在目录上得到了这个“阻塞”状态--应用程序不知道它的代码实际上是subversion工作副本，所以当更新一个插件时，它会删除该插件的目录(包括.svn目录)，并从新版本的插件中放入一个新目录。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1337170|从包含被阻塞的目录的目录中取回.svn目录。我和--force一起结账。例如，如果plugin_dir标记为"~"，则从其父目录运行：|1337171|svn+checkout+--force+http://svn.server.hostname/path/to/repo/and/plugin_dir|code-block|syntax|javascript|1337172|已经存在的任何文件都将被保留，并在签出命令的输出中标记为"E“(当我运行svn+status时，标记为"M”)。|1337173|有时我不得不返回并添加更新中的任何新文件；或者删除应该作为更新的一部分删除的文件，因为它们在我检出时会重新出现。我相信这些在结账时被标记为"A“，但随后的svn+status不会提到它们。|1337174|entityMap^0|36|4|0|F|4|O|7|15|A|0|0|10|A|0|25|A|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|R|$]]

I get this "obstructed" status on directories when I do updates to a CMS (WordPress or Drupal) through the web interface -- the application is unaware that its code is actually a subversion working copy, so when updating a plugin it removes that plugin's directory (including the <code>.svn</code> directory) and drops in a new directory from the new version of the plugin.

To get that <code>.svn</code> dir back, from the directory containing the obstructed dir. I do a checkout with <code>--force</code>. For example, if <code>plugin_dir</code> is marked "~", from its parent directory I run:

<pre><code>svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
</code></pre>

Any files already there are left alone and marked "E" on the output of the checkout command (marked as "M" when I run <code>svn status</code>). 

I sometimes have to go back and add any files that were new with the update; or delete files that should be deleted as part of the update, since they re-appeared when I did the checkout. I believe these are marked as "A" on the checkout, but a subsequent <code>svn status</code> won't mention them.

blocks|key|1552784|text|我在Eclipse中遇到了这种情况，其中一些文件用红色感叹号标记。问题是源目录中有一个迷路的.svn文件夹。我删除了.svn文件夹，刷新了eclipse，并且能够检入文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1552785|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I ran into this in Eclipse where some files were marked with a red exclamation point. The problem was a stray .svn folder in the source directory. I deleted the .svn folder, refreshed eclipse, and was able to check in the files.

blocks|key|1552806|text|当您将subversion升级到XCode不支持的版本时，也会发生这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1552807|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This can also happen when you upgrade your subversion to a version that XCode does not support.

blocks|key|1337194|text|当我用一个名称完全相同的文件夹替换一个文件时，我就想到了这个问题。解决方法是删除旧文件，提交，然后添加新文件。有点老生常谈，但对我很有效:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1337195|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This occurred to me when I replaced a file with a folder, having the exact same name.
Solved by deleting the old file, commit, and then add the new one.
A little hacky, but worked for me :)

blocks|key|1337199|text|我删除了受阻目录中的.svn，并从外部更新了它。然后，外部svn命令将识别这些文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1337200|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I deleted .svn in obstructed directories and update it from outside. Then outside svn command will recognize these files.

What the heck does "obstructed" mean when you try to check into Subversion? I see two folders in red with text status of "obstructed." I don't see what this means anywhere in the docs.

When I try the <code>cleanup</code> command, I get "folder name is not a working directory." This is a folder I just created in VS, and when I try to add it to Subversion it gives me that error. All other folders are fine.

Obstructed folders in Subversion

WordPress

Eclipse

Drupal

当你试图签入Subversion时，“受阻”到底是什么意思？我看到两个红色的文件夹，文本状态为“受阻”。我在文档里看不到这是什么意思。当我尝试cleanup命令时，我得到“文件夹名不是工作目录”。这是我刚刚在VS中创建的一个文件夹，当我尝试将它添加到Subversion时，它会提示我这个错误。所有其他文件夹都没问题。

问Subversion中的受阻文件夹
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Subversion中的受阻文件夹EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Subversion中的受阻文件夹
EN