「svn cleanup」が失敗した場合はどうすればよいですか？

作業フォルダに多くの変更があり、アップデートを実行しようとして何かが失敗しました。

ここで「svn cleanup」を発行すると、次のようになります。

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cppは、別の開発者が追加した新しいファイルであり、アップデートで削除されました。以前は自分の作業フォルダに存在していませんでした。

リポジトリの新しいコピーをチェックアウトせずに、前に進むためにできることはありますか？

明確化：ディレクトリを邪魔にならない場所に移動し、新しいコピーを削除することについての提案に感謝します。私はそれがオプションであることを知っていますが、いくつかのディレクトリにネストされた多くの変更があるため、これは避けたいものです（これはブランチであるはずです...）

私はクリーンアップを実行するより積極的な方法を望んでいます、おそらくファイルSVNを既知の状態に戻すのに問題があることを強制する何らかの方法で（そして私はそれの作業コピーを削除しようとしました...それは助けにはなりませんでした）。

最初からやり直すことはオプションではありません...

.svnディレクトリ内のログファイルを削除し（問題のファイルもで削除しました.svn/props-base）、クリーンアップを行い、更新を再開しました。

SVN 1.7では状況が変更されており、.svnディレクトリのログファイルを削除するという一般的な解決策は、データベースの作業用コピーの実装への移行では実現できません。

これが私がやったことでうまくいったようです：

1. 作業コピーの.svnディレクトリを削除します。
2. 新しい一時ディレクトリで新しいチェックアウトを開始します。
3. チェックアウトをキャンセルします（すべてが引き下げられるのを待ちたくありません）。
4. このキャンセルされたチェックアウトでクリーンアップを実行します。
5. これで、クリーンなデータベースを含む新しい.svnディレクトリが作成されました（ただし、ファイルはほとんどありません）。
6. この.svnを古い、壊れた作業ディレクトリにコピーします。
7. svn updateを実行すると、新しい部分的な.svnディレクトリが古い作業ディレクトリと同じ速度になるはずです。

これは、少しわかりにくく、プロセス的には賢明です。基本的には、破損した.svnを削除してから、同じチェックアウトパス用に新しい.svnを作成しています。次に、この新しい.svnを古い作業ディレクトリに移動して、リポジトリに更新します。

TSVNでこれを実行したところ、問題なく動作し、完全なチェックアウトとダウンロードは必要ありません。

-ジョディ

を見てみましょう

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

上記のリンクからの修正の概要（Anuj Varmaに感謝）

1. sqliteコマンドラインシェル（sqlite-tools-win32）をhttp://www.sqlite.org/download.htmlからインストールします。

2. sqlite3 .svn/wc.db "select * from work_queue"

SELECTは、問題のあるフォルダー/ファイルを作業キューの一部として表示します。作業キューからこのアイテムを削除する必要があります。

3. sqlite3 .svn/wc.db "delete from work_queue"

それでおしまい。これで、クリーンアップを再度実行できます。これで問題なく動作するはずです。または、クリーンアップ（新しいファイルの追加など）を実行するように求められる前に、実行していたタスクに直接進むことができます。

他のすべてが失敗した場合：

1. 新しいフォルダにチェックアウトします。
2. 変更したファイルをコピーします。
3. もう一度ご確認ください。
4. 古いフォルダを削除して新しいフォルダを使用する前に、古いフォルダをどこかに圧縮してください（+パラノイアが良いとは限りません）。

最新バージョン（私は1.9.5を使用しています）では、クリーンアップメニューに[ロックの解除]オプションを追加することで、この問題を解決しています。クリーンアップを行うときは、このチェックボックスがオンになっていることを確認してください。

この回答は、1.7より前のバージョンにのみ適用されます（@ŁukaszBachmanに感謝）。

Subversionはその情報をフォルダー（.svn内）に保存するため、サブフォルダーを処理するだけであれば、リポジトリ全体をチェックアウトする必要はありません。

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

これにより、borkedフォルダーの適切な作業コピーが得られますが、変更はborked_dir.bakにバックアップされています。同じ原則がWindows / TortoiseSVNにも当てはまります。

隔離されたフォルダに変更がある場合は、

svn checkout -N borked_dir   # Non-recursive, but deprecated

または

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

その後

$ svn update

それが役に立てば幸い

私はまったく同じ問題を抱えていました。コミットできず、クリーンアップに失敗しました。

コマンドラインクライアントを使用すると、ファイルをから.svn/propsに移動できなかったことを示すエラーメッセージが表示されました.svn/prop-base。

特定のファイルを調べたところ、読み取り専用とマークされていました。読み取り専用属性を削除した後、フォルダーをクリーンアップして変更をコミットすることができました。

大文字だけが異なる2つのファイル名に問題がある可能性があります。この問題が発生した場合、別の作業用コピーディレクトリを作成しても問題は解決しません。

現在のWindows（すなわち安っぽいが）の違いを完全に理解していないだけでファイルシステムをFilenameとFILEname。2つの可能な修正があります。

1. 実際のファイルシステム（Unixベース）を使用してプラットフォームでチェックアウトし、ファイルの名前を変更して、変更をコミットします。
2. Windowsにストックされている場合、Eclipse SVNリポジトリブラウザーでファイルの名前を変更できます。このブラウザーは、違いを認識し、そこでファイルの名前を変更します。
3. コマンドラインのSVNクライアントからリモートで問題のあるファイルの名前を変更することもできます svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

svn cleanupターミナルでコマンドを実行します（私の場合、Eclipseで失敗した場合）：

~/path/to/svn-folder/$ svn cleanup

ここで説明されているさまざまな解決策を試しましたが、うまくいきませんでした。

アクションチーム → ヘッドへの更新が失敗する：

svn：E155004：「/ home / user / path / to / svn-folder」に未完成の作業項目があります。最初に「svn cleanup」を実行します。

アクションチーム → クリーンアップは同じエラーで失敗します。

私のために働いた解決策：ターミナルでsvn cleanupコマンドを実行します。

コマンドは成功しました。

その後、Eclipse → Team → Updateが再び機能しました。

注：私のSVNバージョンは1.9.3です。

うまくいかない場合は、Chrisの回答も確認してくださいsvn cleanup。

svn cleanupコンソールから実行しようとしたところ、次のようなエラーが発生しました。

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

そのため、このファイルを手動で（空に）作成し、svn cleanup再度作成しました。今回は大丈夫でした。

私も同じ問題を抱えていました。私にとっての原因は、EasySVNおよび（TortoiseSVNまたは単にSVN）との競合でした。EasySVNで自動更新してコミットしました（機能していませんでした）。

これをオフにすると、クリーンアップ、コミット、または更新できませんでした。上記の解決策はどれもうまくいきませんでしたが、再起動するとうまくいきました:)

Windows 7 64ビットでも同じ問題が発生しました。私は管理者としてコンソールを実行し、問題のあるディレクトリから.svnディレクトリを削除しました（ログなどに関するエラーが発生しましたが、無視しました）。次に、エクスプローラーで、バージョン管理下として表示されなくなった問題のディレクトリを削除しました。その後、更新を実行すると、期待どおりに処理が進みました。

問題が大文字と小文字の区別であり（MacとWindowsにチェックアウトするときに問題になる可能性があります）、* nixシステムにチェックアウトするオプションがない場合は、次のように動作します。これが最初からのプロセスです：

% svn co http://[domain]/svn/mortgages mortgages

（チェックアウトが続いて…その後…）

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

ここで、SVNは、大文字Header_3_noBookmark.gifと小文字のみが異なる同様の名前の2つのファイルをチェックアウトしようとしていますHeader_3_nobookmark.gif。Macファイルシステムはデフォルトで、このような状況でSVNが窒息するような方法で大文字と小文字を区別しません。そう...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

ただし、svn cleanupご存知のとおり、実行は機能しません。

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gifここでは問題ではありません...前のエラーを過ぎて次のファイルに移動できないだけです。そこで.svn、以外のディレクトリからすべてのファイルを削除し、SVNログを削除しました。これによりクリーンアップ作業が行われたため、問題のファイルをチェックアウトして名前を変更できました。

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

これに続いて、プロジェクトのルートディレクトリに戻り、実行svn upして残りのプロジェクトをチェックアウトすることができました。

同様の問題があるときはいつでも、rsyncを使用して（注：LinuxまたはMac OS Xを使用して）、次のようにしています。

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

そうすれば、チェックアウトは新しくなりますが、作業ファイルは同じです。私にとって、これは常に魅力のように機能します。

私は遅すぎてそれに遭遇しました。私にとっての秘訣は、「クリーンアップ」を選択した後、ポップアップオプションダイアログで「Break Locks」をチェックし、次に「OK」をチェックしたことです。それは私のために無事に片付けました。

サブクリップは、Windowsの真に悪意のあるロック動作に混乱します。アンロッカーはあなたの友達です。これにより、ロックされたファイルを見つけ、強制的にロックを解除できます。

（フォルダを移動して新しいチェックアウトを行う前。）

問題のファイルが含まれているフォルダーを削除します-はい、.svnフォルダーであっても、svn cleanup一番上の/親フォルダーで行います。

私は同じ問題に直面しました。インターネットで検索したところ、以下の記事が見つかりました。その後、私がSVNのセットアップに使用したユーザーとは別のユーザーとしてログインしていることがわかりました。これは、基本的に権限の問題です。

TortoiseSVN（Windows）でこの問題に直面したとき、Cygwinにアクセスして、そこから「svn cleanup」を実行します。それは私のために正しくクリーンアップし、その後すべてがTortoiseSVNから機能します。

ここでの回答は役に立ちませんでしたが、プロジェクトを再度チェックアウトする前に、Eclipseを閉じて開き（Subversiveは私のSVNクライアントです）、問題は解消しました。

すべての状況に当てはまるわけではありませんが、最近この問題が発生したときの私の「修正」は、システムのSubversionパッケージをアップグレードすることでした。私は1.4.somethingを実行していましたが、最新（私の場合は1.6.6）にアップグレードすると、チェックアウトが機能しました。

（私はそれを再ダウンロードしようとしましたが、クリーンなディレクトリへのチェックアウトは常に同じ場所でハングしました。）

Windowsのネットワークドライブで読み取り専用ロックが発生することがあります。切断して、再接続してみてください。その後、クリーンアップして更新します。

ここで引用されているソリューションのほとんどを実行した後も、エラーが発生しました。

問題は、大文字と小文字を区別しないOS Xでした。同じ名前で大文字と小文字が異なる2つのファイルがあるディレクトリをチェックアウトすると、問題が発生します。たとえば、ApproximationTest.javaとApproximationtest.javaを同じディレクトリに置くことはできません。ファイルの1つを取り除くとすぐに、問題はなくなります。

アップデートに続いて、SVNがフォルダーが競合していると表示するという問題に遭遇しました。不思議なことに、これはコマンドラインからしか見ることができませんでした-TortoiseSVNはすべて問題ないと考えました。

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup、svn revert、svn updateおよびsvn resolveこれを固定で、すべて失敗に終わりました。

私は最終的に問題を次のように解決しました：

• .svnディレクトリで「sub_dir」を探します
• RC->プロパティを使用して、エントリファイルの「読み取り専用」フラグをオフにします
• エントリファイルを開き、行 "unfinished ..."と対応するチェックサムを削除します
• 読み取り専用フラグを保存して再度有効にする
• my_dirディレクトリに対して繰り返します

その後、すべてが順調でした。

ローカルでの変更はなかったので、変更した場合に危険にさらされるかどうかはわかりません。私は他の人が提案した削除/更新方法を使用しませんでした-（同じ症状で始まった）my_dir / sub_dir / sub_sub_dirディレクトリでそれを試してこの状態にしたので、事態を悪化させる危険を冒したくなかった再び！

あまり話題にはなりませんが、誰かがこの投稿を見つけた場合に役立つかもしれません。

ダメダメダメ！SVN 1.7以降を使用している場合は、クリーンアップコマンドで十分です。

私もいくつかの実験を行ったところ、解決策（少なくともEclipseでは）が、プロジェクト全体ではなく、エラーメッセージで指定されたフォルダーに対してのみクリーンアップを実行していることがわかりました。

私がやったsudo chmod 777 -R .パーミッションを変更できるようにします。なしsudoでは機能せず、他のコマンドを実行するのと同じエラーが発生します。

これでsvn update、ディレクトリ全体をスクラップして再作成する必要なく、何でもできます。IDEまたはテキストエディターで特定のタブが既に開いているか、同期の問題が発生している可能性があるため、これは特に役立ちます。作業ディレクトリをスクラップしてこのメ​​ソッドで置き換える必要はありません。

この問題は、同僚の.svnディレクトリを私のものにコピーしてから、作業コピーを更新することで解決しました。それは素晴らしく、素早く、そしてクリーンなソリューションでした。

前の回答には非常に優れた提案がいくつかありますが、WindowsでTortoiseSVNに問題がある場合（優れた製品ですが...）常にコマンドラインにフォールバックし、簡単な「svn cleanup」を最初に実行します。

多くの状況で、Windowsクライアントはクリーンアップコマンドを実行しませんが、クリーンアップはSVNコマンドラインユーティリティを使用して正常に機能します。

同様の問題に直面している間、リポジトリの同期ビューで手動でマージすると、問題を解決するのに役立ちました。

1つのファイル名が他のファイル名と競合しており、問題を明確に述べていました。新しいファイルの名前を別の名前に変更すると解決しました。