（もちろん、それが私のせいであるかどうかはあまり気にしませんが、なぜ物事が起こっているのかはもちろん...）
リモートサーバーのSVNにレールサイトがあります。ローカル コピーで切り替え (svn switch http://whatever/branch .) を実行すると、状況が完全に奇妙になり、サイトが機能しなくなります。最終的に追跡したところ、ビルドの一部 (特に app/config ディレクトリ) が間違ったブランチを指していることがわかりました。ご注意ください：
作業ディレクトリの一部が間違った場所を指している可能性についてのアイデアはありますか? 私の記憶では、作業ディレクトリの一部のサブが間違った場所を指しているのはこれが初めてではありません...なぜこれが起こるのでしょうか?
公式の Subversion FAQ には、スイッチの問題に関するセクション全体があります。それは言います：
作業コピーにバージョン管理されていない (そしておそらく無視されている) 項目がある場合、svn switch はエラーを受け取ることがあります。切り替えが停止し、作業コピーが半分切り替えられたままになります。
彼らのアドバイスは、クリーンな作業コピーからのみ切り替えることです。
もう 1 つはMixed Revision Working Copiesです。
基本的にこれは、作業コピー内のファイルが異なるリビジョンからのものである可能性がある (通常はそうである) ことを意味します。
SVN Red Bookがこれについて述べなければならないことは次のとおりです (私が強調):
たとえば、完全にリビジョン 10 の作業コピーがあるとします。ファイル foo.html を編集してから、リポジトリにリビジョン 15 を作成する svn commit を実行します。コミットが成功した後、多くの新規ユーザーは作業コピーが完全にリビジョン 15 であることを期待しますが、そうではありません!リビジョン 10 から 15 の間で、リポジトリ内でいくつもの変更が発生した可能性があります。svn update をまだ実行しておらず、svn commit が新しい変更をプルダウンしていないため、クライアントはリポジトリ内のこれらの変更について何も知りません。一方、svn commit が最新の変更を自動的にダウンロードする場合、作業コピー全体をリビジョン 15 に設定することは可能ですが、「プッシュ」と「プル」の基本的なルールを破ることになります。残りの個別のアクション。したがって、Subversion クライアントができる唯一の安全な方法は、1 つのファイル (foo.html) をリビジョン 15 としてマークすることです。残りの作業コピーはリビジョン 10 のままです。svn update を実行することによってのみ、最新の変更をダウンロードできます。作業コピー全体がリビジョン 15 としてマークされます。
何をしているのか分かっていたらすみませんが、そうではないようです。（または質問が明確ではありません）。関連するディレクトリからのsvn statusの結果を含めると、さらに先に進むことができます。
svn switch
(svn ヘルプ スイッチ)
これは、一般的なワークフローの一部であってはならないリポジトリを切り替えるためのものです。