SVNエラー-作業コピーではありません

最近、svnサーバーが変更され、svnスイッチを実行しました。

作業コピーにはバージョン管理されていない大量のリソースがあったため、作業コピーがロックされ、svnの下のすべてのフォルダーについてフォルダーごとの切り替えを開始しました。

しかし、リポジトリの最上位レベルでファイルを更新しようとすると、svn：Working copy '。'が表示されます。ロックされたエラーとクリーンアップも役に立ちません。クリーンアップを実行すると、次のようなエラーが発生します-svn： 'content' is not a working copy directory

フレッシュチェックアウトはオプションではありません。ロックをクリーンアップして解放し、完全に切り替える方法は他にありますか？

編集： JesperEの答えの最後の段落

再帰的な「svn cleanup」を実行しているときに「作業コピーではない」というメッセージが表示された場合、作業コピーであるはずのディレクトリ（つまり、トップレベルの.svnディレクトリがそうだ）があると思いますが、それがありません独自の.svnディレクトリ。その場合は、そのディレクトリを削除または移動してから、ローカル更新を行うことができます

リポジトリの問題の解決策のようです。私はそれらのフォルダーを識別し、それらの特定のフォルダーのみを新たにチェックアウトしましたが、その後のクリーンアップでロックが解放されました！どうもありがとうJesperE !!

しかし、私はまだsvn switchエラーを理解できません。現在は次のようになっています。

svn： 'svn：// repourl / reponame / foldername'のリポジトリにはuuid 'm / reponame'がありますが、WCには 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'があります

何か案は ？

再帰的に「作業コピーではない」というsvn cleanupメッセージが表示された場合、作業コピーであるはずのディレクトリがある（つまり.svn、最上位のディレクトリがそうしている）が、独自の.svnディレクトリが欠落していると思います。その場合は、そのディレクトリを削除または移動してから、ローカル更新（つまりrm -rf content; svn checkout content）を実行してみてください。

あなたが取得した場合not a working copy、エラーが、それはSubversionは、適切な見つけることができないことを意味.svnそこにディレクトリを。に.svnディレクトリがあるかどうかを確認しますcontents

理想的な解決策は、可能であれば新しいチェックアウトです。

私は似たような状況（svn: 'papers' is not a working copy directory）に別の方法で行ったので、自分のバトルストーリー（簡略化）を投稿すると思いました：

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

おっとっと！権限を修正します...次に：

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

そしてpapers、邪魔にsvn upならないところに移動して実行しても（OPで機能しました）、それは修正されませんでした。これが私がしたことです：

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

うまくいきました。

私はそれを解決しました

1. 影響を受けるフォルダーのバックアップをコピーする
2. SVNは影響を受けるフォルダーを元に戻します
3. バックアップからファイルを貼り付けます

私の場合、問題は削除された.svn-filesが原因でした。

たぶん、あなたはフォルダのツリーをコピーして、最も低いものを追加しようとしました。

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

その場合、上位レベルのディレクトリをコミットする必要があります。

回避策：「作業用コピー」ではないディレクトリの名前を変更するこのディレクトリをもう一度チェックアウト/更新/復元するファイルを名前を変更したディレクトリから新しいコミットに移動する変更をコミットする

理由：.svnディレクトリーの下のいくつかのファイルに変更を加えたため、「作業用コピー」が壊れます

新しいディレクトリ内にファイルを作成した場合、「svn add newdir / newfile」の代わりに「svn add newdir」を使用してください。ディレクトリを追加する必要があるためです。デフォルトでは、ディレクトリ内のすべてのファイルが追加されます。

私は「作業コピーではありません」を取得しました。その理由は、UnixのAutoMouterでした。新鮮な "cd / path / to / work / directory"がうまくいった。

同じように、「contrib」フォルダーを更新する必要がありました。

1. 古いフォルダを移動しました、
2. 新しいものをコピーしました
3. .svnフォルダーをそれぞれの（私の場合は3つだけ）新しいフォルダーにコピーしました。

私の場合も、問題は削除された.svnフォルダーが原因でした。

解決しました。

.svnフォルダーをサブフォルダーからルートフォルダーに貼り付けてみました。できます！！！

これは私がやったことです：

1. トランクの名前をtrunk_に変更します
2. 新しいフォルダートランクを作成する
3. いくつかのファイルがチェックアウトされた後、プロセスを再チェックアウトして中断します
4. ファイルをtrunk_からtrunkに移動します
5. SVNクリーンアップを実行
6. svn updateを実行します。これによりファイルのステータスが更新され、すべてのファイルがバージョン管理されます。

また、svn diff操作でこの問題に遭遇しました。これは、不正なファイルパスが原因'./'でした。現在のファイルディレクトリを示すために追加する必要があります。

svn： 'svn：// repourl / reponame / foldername'のリポジトリにはuuid 'm / reponame'がありますが、WCには 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'があります

すべてのSubversionリポジトリには一意の識別子（uuid）があります。Subversionはこれを使用して、切り替えなどを行うときにリポジトリが実際に同じであることを確認します。サーバーのuuidを以前と同じに変更する必要があります。

作業コピーの形式が一致していない可能性がありますか？svn 1.4と1.5の間で変更され、新しいツールは自動的にフォーマットを変換しますが、古いツールは変換されたコピーで動作しなくなります。

プロジェクトからSVN-基本ファイル（読み取り専用ファイル）を削除しておく必要があります。このため、このエラーが発生します。

もう一度新しいプロジェクトをチェックアウトし、「Winmerge」を使用して古いSVNプロジェクトの変更（ある場合）を新しいプロジェクトとマージし、最新のチェックアウトで変更をコミットします。

@JesperE は、uuidを変更する必要があると述べています。以下はこれを達成するのに役立ちます。

SVN 1.5以降では、svnadmin setuuidを実行できます。次に、svnlook uuidを使用して、正しく設定されていることを確認できます。SVNの以前のバージョンでは、これはより難しいプロセスです。http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.htmlを参照してください

さらに、「m / reponame」のUUIDは疑わしく見えます。私はそれが作業コピーのような16進形式の数値であるべきだと思うので、おそらくこのアクションはすべての点で改善されます:-)

[元々は@JesperEの回答にコメントしていましたが、この回答を作成して人々にわかりやすくし、Googleにとってより役立つようにしました。それ以来コメントを削除しました。]

これと同じ問題が発生したため、同じマシンにSlik 1.6.2とTortoiseがインストールされていることがわかりました。Tortoiseは更新されました（そして作業コピーを更新しました）が、Slikは更新されていなかったため、Tortoiseは問題なく動作しましたが、コマンドラインは次のように失敗しました：

svn： '。' 作業コピーのディレクトリではありません

TortoiseとSlikの両方を削除してから、コマンドラインツールを有効にしてTortoiseを再インストールすると、これが修正されました。

Macの場合：-サーバー側からチェックアウトすると、ローカルマシンからディレクトリを選択するための新しいウィンドウが開き、選択したフォルダーにすべてのコードを配置してから、svnローカル側を開き、プロジェクトを追加してコミットします

今日、私は/FILE_NAME/ is not a working copy朝に同じ問題を発見し、それを解決するために2時間以上費やしました。RNDとGoogleの長い間、私はいくつかの解決策を見つけました、それはCHECKOUTです。

1. CHECKOUTSUBVERSION新しいプロジェクトとしてローカルから。
2. Javaファイルのコードの一部を変更し、プロジェクトをコミットします。
3. それは私にとっては作品です。

お役に立てれば幸いです。

最近、他の開発者のMacを使っていましたが、同じ状況で問題がありました。最初にget repo path to terminalと入力する必要がありましたが、入力しませんでした。ユーザー名とパスワードを教えてくれるからです。

.svnディレクトリが別のマシンのnfsサーバーにあり、nfsクライアントがファイルロックサービス（lockd）を実行していない場合に遭遇しました。

svn: E155007: '/mnt/svnworkdir' is not a working copy

これはlockd、nfsクライアントホストで開始されたときになくなりました。

ファイルのロックに問題がある場合、subversionはより適切なエラーメッセージを表示できるようです。これはsubversion 1.10.0でした

同じプロジェクトから別の場所に新しいチェックアウトを作成し、そこから.svnフォルダーをコピーして、古い.svnフォルダーに置き換えました。その後、svn update関数を呼び出し、すべてが正しく同期されました。

ローカルマシンにある.svnフォルダーを削除します。Windowsアイコンを押して.svnと入力し、フォルダ全体を削除します。それは私のために働いた。