SVN Weirdness: Is It Possible It's Not My Fault

Question

(I don't really care if it's my fault but rather why things are happening, of course...)

I have a rails site in SVN on a remote server. On my local copy I do a switch (svn switch http://whatever/branch .), and then things are totally bizarre and the site doesn't work. I finally track it down and it turns out that part of the build (particularly, the app/config directory) is pointing to the wrong branch. Please note:

• I never switch using anything other than the SVN command line
• I only switch at the root of the installation
• I always switch as root (sudo -s) and I'm sure that the permissions were set correctly on the whole tree (chmod -R 777)

Any ideas on how part of the working directory could end up pointing to the wrong place? In my memory, this is not the first time that some sub of the working directory is pointing to the wrong place... why would this happen?

Answer 1

Excuse me if you know what you're doing, but it sounds like you aren't. (Or the question isn't clear). If you include the results of svn status from the relevant directories, we could get farther.

svn switch

(svn help switch)

is for switching repositories, which shouldn't part of a common workflow.

Answer 2

There is a whole section about switch problems in the official Subversion FAQ. It says:

In some cases where there are unversioned (and maybe ignored) items in the working copy, svn switch can get an error. The switch stops, leaving the working copy half-switched.

Their advice is to only switch from a clean working copy.

Another thing is Mixed Revision Working Copies.

Basically this means that the files in your working copy can be (and normally are) from different revisions.

Here is what the SVN Red Book has to say about this (emphasis by me):

For example, suppose you have a working copy entirely at revision 10. You edit the file foo.html and then perform an svn commit, which creates revision 15 in the repository. After the commit succeeds, many new users would expect the working copy to be entirely at revision 15, but that's not the case! Any number of changes might have happened in the repository between revisions 10 and 15. The client knows nothing of those changes in the repository, since you haven't yet run svn update, and svn commit doesn't pull down new changes. If, on the other hand, svn commit were to automatically download the newest changes, then it would be possible to set the entire working copy to revision 15—but then we'd be breaking the fundamental rule of “push” and “pull” remaining separate actions. Therefore the only safe thing the Subversion client can do is mark the one file—foo.html—as being at revision 15. The rest of the working copy remains at revision 10. Only by running svn update can the latest changes be downloaded, and the whole working copy be marked as revision 15.