SVNチェックサムを修復する

Question

Flex Builder 3 で subclipse を使用していますが、最近コミットしようとしたときに次のエラーを受け取りました。

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

私は次のようにしてそれを回避しました。

1. 他のすべての変更されたファイルをコミットし、面倒なファイルを省略します。
2. トラブル ファイルの内容を TextMate ウィンドウにコピーする
3. FlexBuilder/Eclipse でプロジェクトを削除する
4. SVN から新しくプロジェクトをチェックアウトしています
5. トラブル ファイルのテキストを TextMate ウィンドウからコピーして戻す
6. 変更をコミットします。

それはうまくいきましたが、もっと良い方法があると思わずにはいられません。svn:checksum エラーの原因として実際に何が起こっているのか、そして最善の修正は何なのか。

おそらくもっと重要なことですが、これはより大きな問題の兆候なのでしょうか?

Answer 1

特定のファイルについて、いつ、どのリビジョン、どこからチェックアウトしたかを追跡する .svn ディレクトリ内のファイルが何らかの理由で破損しました。

これは、通常の奇妙なファイルの問題と同じくらい危険でも重大でもありません。原因としては、変更途中で停止する破壊プログラムや電源障害など、さまざまな問題が考えられます。

それがもっと起こらない限り、私はそれからあまり得られないでしょう。

これは、作業ファイルのコピーを作成し、新しいコピーをチェックアウトして、変更したファイルを再度追加することで修正できます。

通常は変更をマージする必要があるビジーなプロジェクトがある場合、これにより問題が発生する可能性があることに注意してください。

たとえば、あなたと同僚の両方が新しいコピーをチェックアウトし、同じファイルで作業を開始するとします。ある時点で、同僚が自分の変更をチェックインします。同じことを行おうとすると、チェックサムの問題が発生します。ここで、変更したファイルのコピーを作成し、新たにチェックアウトを行うと、Subversion は変更をどのようにマージしなおすべきかを追跡できなくなります。

この場合に問題が発生しなかった場合は、変更をチェックインするときに、最初に作業コピーを更新し、場合によってはファイルとの競合に対処する必要があります。

ただし、同僚による変更を完了して新たにチェックアウトを行うと、同僚の変更を削除して自分の変更に置き換えたように見えます。競合はなく、何かが間違っているという転覆による兆候もありません。

Answer 2

これには、単なるバグやディスクの破損などではなく、もっと単純な原因もあります。この問題が発生する最も可能性の高い原因は、誰かが .svn ファイルを除外せずに作業コピーに再帰的なテキスト置換を書き込んだ場合だと思います。
これは、ファイルの元のコピー (基本的には、.svn 管理領域内に保存されているファイルの BASE バージョン) が変更され、MD5 合計が無効になることを意味します。

@アンドリュー・ヘッジズ:これは、ソリューションがこの問題を解決する理由も説明します。

Answer 3

SVN は、チェックアウトしたすべてのファイルの元のコピーを .svn ディレクトリに埋め込んで保持します。これをテキストベースと呼びます。これにより、迅速な差分と復帰が可能になります。さまざまな操作中に、SVN はこれらのテキストベースのファイルに対してチェックサムを実行し、ファイル破損の問題を検出します。

一般に、SVN チェックサムの不一致は、変更されるべきではなかったファイルが何らかの理由で変更されたことを意味します。それはどういう意味ですか？

1. ディスクの破損 (HDD または IDE ケーブルの不良)
2. 不良RAM
3. 不正なネットワークリンク
4. 何らかのバックグラウンド プロセスが背後でファイルを変更しました (マルウェア)

これらはすべて悪いものです。

しかし, あなたの問題は違うと思います。エラーメッセージを見てください。いくつかの MD5 ハッシュを予期していましたが、代わりに「null」が返されたことに注意してください。これが単純なファイル破損の問題であれば、expected/got に対して 2 つの異なる MD5 ハッシュがあると予想されます。「null」があるという事実は、何か他の問題が発生していることを意味します。

私には 2 つの理論があります。

1. SVNのバグ。
2. 何かがファイルに排他ロックを持っていたため、MD5 は発生できませんでした。

#1 の場合は、最新の SVN バージョンにアップグレードしてみてください。これを svn-devel メーリング リスト (http://svn.haxx.se）、開発者がそれを見ることができます。

#2 の場合は、ファイルがロックされていないか確認してください。Process Explorer のコピーをダウンロードして確認できます。おそらく、誰がロックを持っているかを確認したいことに注意してください。 テキストベース ファイルではなく、コミットしようとした実際のファイルです。

Answer 4

私も同様の現象を時々受け取ることがありますが、たいていは何週間も誰もアクセスしていないファイルです。通常、問題のディレクトリで作業していないことがわかっている場合は、問題のあるディレクトリを削除して、次のコマンドを実行できます。

svn update

それを再作成するために。

ディレクトリにライブ変更がある場合は、lassevk 氏やあなた自身が提案したように、より慎重なアプローチが必要です。

一般的に言えば、編集したファイルをコミットせずに放置せず、作業コピーを整理整頓しておくことをお勧めします。使用しない大量の余分なファイルを作業コピーに追加しないでください。定期的にコミットしておくと、作業コピーがおかしくなった場合でも、すべてを削除して最初からやり直すことができます。何が失われるかどうかを気にしたり、どのファイルを保存するかを考える手間をかけたりする必要はありません。

Answer 5

ちょうど今日、破損したディレクトリのコピーを /tmp にチェックアウトし、.svn/text-base 内のファイルを先ほどコピーしたファイルで置き換えることで、このエラーからなんとか回復しました。手順を詳しく書きました 私のブログのここに. それぞれのアプローチの長所と短所について、より経験豊富な SVN ユーザーから聞きたいと思っています。

Answer 6

試す：svn up --force file.c

これは特別なことをしなくてもうまくいきました

Answer 7

私は、.svn/entries ファイルのパッチ適用から新たなチェックアウトまで、多くのソリューションを観察してきました。

それは新しい方法かもしれません (私の同僚に感謝します):

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

Answer 8

Matt、あなたが説明したよりも簡単な方法があります - .svn/entries ファイルのチェックサムを変更します。完全な説明は次のとおりです。http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

私が見つけたチェックサム競合のもう 1 つの回避策は、おそらくさらに恐ろしいもので、次のとおりです。

警告： ローカル コピーが最もよく知られているバージョンであること、そしてプロジェクトの他の誰もがあなたが何をしているのかを知っていることを確認してください。(これがまだ明らかでない場合に備えて)。

ファイルのローカル コピーが「適切なもの」であることがわかっている場合は、SVN サーバーからファイルを直接削除してから、ローカル コピーを強制的にコミットできます。

直接削除の構文:

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

幸運を！

J

Answer 10

新しいコピーをチェックアウトし（これは他のすべてのオプションを試した後で行う必要がありました）、以前に保存したすべての変更をマージして戻す代わりに、次のアプローチでも同様に機能しましたが、かなりの量を節約できました。時間がかかり、おそらくいくつかのエラーが発生します。

1. 新しい作業コピーをチェックアウトする
2. .svn フォルダーを新しいコピーから破損したコピーにコピーします
3. 出来上がり

もちろん、万が一に備えて元の破損した作業コピーをバックアップする必要があります。私の場合は、すべてがうまくいったため、完了後に自由に削除できました。

Answer 11

これは、.svn フォルダーが破損した場合に発生します。解決：ファイルが含まれるフォルダー全体を削除し、フォルダーを再度チェックアウトします。

Answer 12

この問題が発生した場合、開発 VM はすべて *nix ワークステーション win32 です。一部の愚か者は、 *nixボックスに同じ名前（異なるケース）のファイルを作成しました。WinがMD5に対して同じ名前の2つのファイルのどれがわからないので、 *nixのチェックアウトは問題ありませんでした...少し頭を悩ませることになります

適切な作業コピーを含む *nix ボックスから「.svn」フォルダーをコピーすることで、Win ボックス上のリポジトリを更新することができました。完全なチェックアウトを再度実行できるレベルまでリポジトリをクリーンアップできるかどうかはまだ確認していません

Answer 13

もう一つの簡単な方法....

1. プロジェクトを更新して最新バージョンを取得します
2. 別のフォルダーにある同じバージョンをチェックアウトする
3. .svn フォルダーを新しいチェックアウトから作業コピーに置き換えます (.svn-base ファイルを置き換えました)

Answer 14

1. 問題のあるファイルを含むフォルダーのみをリポジトリから別の場所にチェックアウトします。
2. 確認する .svn\text-base\<problematic file>.svn-base チェックアウトされたものと同じです。
3. 問題のあるファイルセクションを確認してください (セクションの全行) で .svn\entries チェックアウトされたものと同じです。

Answer 15

信じられないかもしれませんが、実際には、 <scm>...</scm> チェックインしようとしていた問題のある pom.xml ファイルからのスタンス。これには、チェックインされている Subversion リポジトリの URL が含まれていました (これが Maven 設定の目的です!) が、どういうわけか、チェックイン中にファイルに欠陥のあるチェックサムが生成されました。

これを修正するために前述のすべての方法を文字通り試しましたが、役に立ちませんでした。チェックサムジェネレータが十分に堅牢ではないという非常にまれな状況に遭遇しましたか?

Answer 16

私もこの問題に遭遇し、簡単な解決策を探していたところ、このスレッドに記載されている解決策のいくつかを試しました。私の開発環境でこの問題を解決した方法は次のとおりです (私にとっては最小限の変更でした)。

1- ファイルが破損したローカルで削除されたディレクトリ (WEB-INF):

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- 新しいチェックアウトからコピーして貼り付けたディレクトリ (WEB-INF)

3- SVN が起動しました。Eclipse/TortoiseSVN がこのディレクトリで競合を示し始めました。

4- 競合を解決済みとしてマークする

これは機能し、以前の破損した web.xml を更新してコミットできました。

Answer 17

私の場合は金額が違いました。私がやったことは次のとおりです。

1) 別フォルダにチェックアウトする

2) .svn ディレクトリ内のこのフォルダーのファイルを、svn クライアントのエラー メッセージで示されたプロジェクトの問題ファイルに置き換えます。

3) ..利益!

Answer 18

これは古い問題ですが、1 時間以上この問題と格闘したばかりなので、私も 2 セント寄付しようと思いました。

上記の解決策は私にとってはうまくいかなかったか、複雑すぎるように思えました。

私の解決策は、プロジェクトからすべての svn フォルダーを単純に削除することでした。

find . -name .svn -exec rm -rf {} \;

この後、再度プロジェクトの簡単なチェックアウトを行いました。したがって、コミットされていないファイルはすべてそのまま残りますが、すべての svn ファイルは再構築されます。

Answer 19

ubuntu 14.04でこの問題が発生し、次の手順で解決しました。

1. $ cd /var/www/myProject
2. $ svn アップグレード
3. $ svn アップデート

これらの手順の後、エラーなしでファイルをコミットできました。

Answer 20

1. 問題の原因となっているフォルダーに移動します
2. コマンドを実行する svn update --set-depth empty
3. このフォルダーは空になり、空のフォルダーに戻ります
4. svnと同期して更新します。

これは私にとっては仕事です。

Answer 21

問題を解決する方法は次のとおりです。簡単ですが、上記の jsh に従って、コピーが最適なものであることを確認する必要があります。

単に

1. 問題のあるすべてのファイルを同じフォルダーにコピーします。
2. svn rm で古いものを削除します
3. 専念。
4. 次に、コピーの名前を元のファイル名に戻します。
5. 再度コミットします。

おそらくこれにより、そのファイルのあらゆる種類のリビジョン履歴が消去されるのではないかと思われます。したがって、これはかなり醜い方法です...