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

Question

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 see 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!)

Answer 1

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.

Answer 2

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.