SVNの「作業コピー管理領域が含まれていない」の修正方法
リポジトリに追加したばかりのディレクトリをオフラインで手動で削除しました。ディレクトリを復元できません。
更新またはコミットを実行しようとすると失敗します。
"blabla/.svn" containing working copy admin area is missing.
理由はわかりますが、とにかくこれを修正する方法はありますか。
リポジトリ全体をチェックアウトして変更を手動で追加したくないので、数時間かかります。
これによると： http://www.devcha.com/2008/03/svn-directory-svn-taining-working.html
フォルダー「blabla」を別の場所にチェックアウトしてから、その.svnフォルダーをコピーして元の「blabla」に戻します。
fwiw、同様の状況があり、svn --force delete __dir __を使用しました。これで問題は解決しました。その後、通常どおり作業用コピーで作業を続けました。
これを修正するためにしたことは、 地元 問題のフォルダのコピーを作成し、その後すぐに親のsvn updateを実行します。
それを直しました。
親ディレクトリの新しいコピーをチェックアウトできますか？
編集：もう少し具体的に言うと、1つ上のレベルに移動して、含まれているディレクトリを削除することをお勧めします。それから
svn update --set-depth infinity
ディレクトリを置き換えます。
Svnにディレクトリを追加した後、誤って.svnフォルダーを削除しました。
使った
svn delete --keep-local folderName
私の問題を修正します。
私はちょうど 'svn revert/blabla'を実行しましたが、それは機能しました、フォルダが戻ってきて、それをsvn削除できます
ディレクトリをリポジトリに追加しようとしたときに、「作業コピー管理領域を含むディレクトリ 'blah/.svn'がありません」というエラーが発生しましたが、ファイルシステムの権限が十分ではありませんでした。ディレクトリはまだリポジトリにありませんでしたが、追加に失敗した後はバージョン管理下にあると主張していました。
親ディレクトリのコピーを別の場所にチェックアウトし、作業コピーの親ディレクトリにある.svnフォルダーを置き換えると、新しいディレクトリを追加してコミットできました（もちろん、ファイルのアクセス許可を修正した後）。
私はsvn rm --force /path/to/dirを試してみましたが、結局svn upを実行するだけになり、それを修正しました。
私たちはmavenとsvnを使用します。このエラーの原因は、SVNへのターゲットディレクトリの誤ったチェックインでした。このヒントが誰かに役立つなら、それを削除することですべてが修正されました。
私を助けた最も簡単なもの：
rm -rf _dir_in_question_
svn up
問題のあるディレクトリに変更がある場合、これは良い解決策ではありません。
あなたの投稿からあまり理解していませんでした。私の解決策は
- 問題のあるフォルダーを切り取り、ある場所にコピーします。
- Subversionから別の作業ディレクトリ（新しいディレクトリのみ）にソリューションを取得します。
- 保存したフォルダーを新しい作業コピーに追加し、既存プロジェクトとして追加します（私の場合のようにプロジェクトの場合）。
- コミット;
「C：\ superfolder」を切り替えようとしたときに、同じ問題が発生しました
エラーメッセージ：
Directory 'C:\superfolder\subfolder\.svn' containing working copy admin area is missing Please execute the 'Cleanup' command.
「クリーンアップ」を試みた後、次のエラーが表示されました。
Cleanup failed to process the following paths: C:\superfolder\ 'C:\superfolder\subfolder\' is not a working copy directory
解決策：
- フォルダ「サブフォルダ」を削除します
- フォルダ「スーパーフォルダ」をクリーンアップします
- フォルダ「スーパーフォルダ」を再度切り替えてみてください
これは私のために働いた。それがあなたにも役立つかどうか私に知らせてください。
この問題がありました。 blablaを一時的に別の場所に移動し、svnに元に戻すように指示してから、元に戻します。新しい追加として扱われます。シンプル！
SVNグローバルの設定によってファイルが除外されたときに、最近このエラーが発生しました。リポジトリからファイルを直接削除したため、このエラーは特に厄介でした。これは、上記の解決策が拒否されたことを意味していませんでした。この場合、SVNから削除したディレクトリから.svnディレクトリを手動で削除すると、更新を実行してコミットできました。
最近このエラーが発生しました。これは、このエラーを与えるディレクトリ内のいくつかのファイルをルートが所有していることが原因でした。
許可を変更した後、すべてが期待どおりに機能しました。
サードパーティのAPIライブラリを新しいバージョンに置き換えると、この問題に出くわしました。SVNバージョンをローカルバージョンに置き換えたいため、ここでのソリューションはどれも本当に役に立ちませんでした。私の解決策は次のとおりでした：
1）問題のフォルダーをホームディレクトリーに移動し、SVNから削除してコミットします。
mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"2）フォルダを元に戻し、SVNに追加して再度コミットします。
mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"2回コミットしなければならないのは少しいらいらしますが、うまくいったようです。
まず、プロジェクトをフォルダー内のシステムにチェックアウトします。次に、競合プロジェクトから.svnフォルダーを削除し、新しいチェックアウトフォルダーから.svnフォルダーをコピーして、作業コピーフォルダーに貼り付けます。その後、問題は解決されます。
私にとっては、両方とも同じ問題が発生しました：
- 削除（
--force）.mapファイル svn:ignore経由で* .mapをsvn propedit svn:ignore .に追加
私の解決策は：
- プロパティへの変更を元に戻す
- ファイルへの変更をコミットする
- リポジトリの新しいコピーをチェックアウトします（alas！）
- プロパティを変更してコミットする
ディレクトリをsvnに追加しようとしたときに、この問題が発生しました。リポジトリブラウザに移動して解決しました。左側のウィンドウを右クリックして、フォルダーの追加を選択し、リポジトリブラウザーで直接ディレクトリを追加します。
その後、ディレクトリをローカルで削除し（もちろんバックアップ後）、クリーンアップとsvn更新を行い、すべてが再び機能しました。
誰かがさらに別のソリューションを望んでいる場合に備えて：
- 新しいフォルダーを「foldername2」としてチェックインします
- Tortise SVNリポジトリブラウザに移動します
- 「foldername2」の名前を「foldername」に変更します
- Windowsエクスプローラーで更新を行います
それが誰かを助けることを願っています。
-Ev
私が経験した一般的なタスクは、ステージングで1つのレポジトリディレクトリを取得し、それを別のレポジトリにコピーすることでした。私のために働いた方法は次のとおりでした：
svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A