SVN: What does the status "switched relative to its parent" mean?

I'm trying to update our live site from the SVN repository. As far as I know, there's nothing in the repos. itself that should conflict with anything in the working copy dir. But when I try to "svn up" on the public root directory, I get the following error:

svn: REPORT request failed on '/svn/oursite/!svn/vcc/default'
svn: Working copy path 'app' does not exist in repository

When I run "svn status" on the docroot, I se开发者_如何学编程e the following:

docroot$ svn st -N
   +S  app
   +S  downloads
   +S  index.php
   (etc.)

According to the docs, the S flag indicates whether the item is switched relative to its parent. What does that even mean, and what can I do to fix this?

EDIT: I should mention that I'm the only one who has worked with the SVN repository. I've been working with it all day, trying to defeat one corruption issue after another as I move things around.

(SVN is great, but it sure is fragile... Seems to break if you just glance at it wrong!)

In the same folder as the one where you ran svn status, run the following command:

svn info app

This will show you at which URL the svn metadata of the app folder is pointing. You'll probably see that it is pointing to another location compared to the one you'd expect based on the URL for the parent folder.

You can then either use svn switch to point each switched folder back at the correct URL, or simply delete each switched folder with rm -rf and then do a svn update.

update after rereading question: Scott is right when he says that switched folders should not cause errors when you do a svn update.

The reason you experience problems with your working copy is because you move around or rename folders without using the svn mv command. This is a classic SVN newbie mistake; I've been involved in training new SVN users and I've seen this alot.

It is quite hard to repair a working copy after such erroneous manipulations. The best way to fix it is typically to just do a fresh checkout. Future versions of SVN will centralize Subversion 1.7 has now centralized the .svn metadata, reducing the opportunity for such mistakes.

I think the directory is corrupted somehow. If it's not a big deal to nuke it, I'm sure that deleting the directory and reupdating/checking out will make the issue go away.

I don't think they're right about the directory being switched, because you can definitely run svn up amidst switched directories without issue.

Here's one guy that solved it the nuking way (http://andychase.net/posts/2006/04/working-copy-path-foo-does-not-exist-repository), and several other instances like that are pretty easily searchable.

I ran into this problem after copying some files from one locally-checked out directory to another, then trying to add the files. The problem was that I had also copied the .svn directory from the source files, which confused the heck out of subversion. Deleting the .svn directory after copying the files fixed my problem.

I just found one solution which worked here. The sequence of actions:

Open a file which only exists in the current branch in a text editor.

1. Switch to another branch.
2. Save the file in the editor.
3. Switch back - It now complains that it can't because the file would be replaced by the switch.
4. Remove the file.
5. Redo the switch. Now all files have status "S".
6. Do the switch yet again. Now it is all happiness in the land of obsolete VCSes.