66

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 エラーを引き起こすために実際に何が起こっているのか、そして最善の修正は何ですか。

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

4

21 に答える 21

38

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

これは、通常の奇妙なファイルの問題よりも危険でも重大でもありません。Subversion プログラムが変更の途中で停止したり、電源が切断されたりするなど、さまざまな問題が原因である可能性があります。

それがもっと起こらない限り、私はそれからあまり利益を上げません。

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

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

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

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

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

于 2008-08-08T16:56:13.027 に答える
20

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

@Andrew Hedges：ソリューションがこれを修正する理由も説明しています。

于 2009-02-23T21:30:14.267 に答える
11

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 のコピーをダウンロードして確認できます。コミットしようとしている実際のファイルではなく、テキストベースのファイルを誰がロックしているかを確認したい場合があることに注意してください。

于 2009-01-25T14:04:32.303 に答える
6

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

于 2009-01-25T08:18:24.103 に答える
5

私はときどき似たようなものを手に入れます。通常は、何週間も誰も近くにいないファイルです。通常、問題のディレクトリで作業していないことがわかっている場合は、問題のあるディレクトリを削除して実行できます

svn update

それを再作成します。

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

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

于 2008-08-09T01:12:37.393 に答える
4

試してください：svn up --force file.c

これは余分なことをすることなく私のために働いた

于 2009-03-06T18:56:18.367 に答える
4

.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
于 2011-05-06T13:58:46.530 に答える
3

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

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

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

直接削除の構文:

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

幸運を！

J

于 2009-11-20T16:17:04.803 に答える
3

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

于 2011-06-30T08:46:50.490 に答える
2

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

于 2014-06-12T14:02:53.710 に答える
2

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

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

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

于 2013-07-08T16:19:33.803 に答える
1

この問題が発生したため、開発 VM はすべて *nix ワークステーション win32 です。何人かの愚か者が *nix ボックスに同じ名前 (大文字と小文字が異なる) のファイルを作成しました Win32 での突然のチェックアウトのすべてが爆発します... win は同じ名前の 2 つのファイルのどちらを MD5 に対して認識していないからです、* nixのチェックアウトは問題ありませんでした...少し頭を悩ませました

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

于 2009-07-07T23:14:41.297 に答える
1

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

  1. プロジェクトを更新して最新バージョンを取得する
  2. 別のフォルダーで同じバージョンをチェックアウトする
  3. .svn フォルダーを新しいチェックアウトから作業コピーに置き換えます (.svn-base ファイルを置き換えました)
于 2012-01-18T21:30:30.050 に答える
0
  1. 問題の原因となっているフォルダに移動します
  2. コマンド実行svn update --set-depth empty
  3. このフォルダは空になり、空のフォルダに戻ります
  4. svn と同期して更新します。

これは私にとってはうまくいきます。

于 2013-07-30T10:48:01.427 に答える
0

私の場合、合計は異なっていました。私がやったことはすべて：

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

2) .svn ディレクトリ内のこのフォルダーのファイルを、svn-client エラー メッセージに記載されているプロジェクトの問題ファイルに置き換えます。

3) ..利益！

于 2013-05-17T09:03:33.750 に答える
0
  1. 問題のあるファイルを含むフォルダーのみをリポジトリから別の場所にチェックアウトします。
  2. .svn\text-base\<problematic file>.svn-baseチェックアウトしたものと同一であることを確認してください。
  3. 問題のあるファイル セクション(セクションのすべての行)が.svn\entriesチェックアウトされたものと同一であることを確認します。
于 2012-04-24T05:05:14.870 に答える
0

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

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 を更新してコミットすることができました

于 2013-04-22T07:50:45.917 に答える
0

<scm>...</scm>信じられないかもしれませんが、チェックインしようとしていた問題のある pom.xml ファイルからスタンスを削除することで、実際にエラーを修正しました。これには、チェックインされているサブバージョン リポジトリの URL が含まれていました (これが Maven の設定は for!) ですが、チェックイン中に何らかの理由でファイルの不正なチェックサムが生成されました。

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

于 2013-01-10T15:19:09.770 に答える
-2

これが私が問題を修正した方法です-vシンプルですが、上記のjshに従って、コピーが最適なものであることを確認する必要があります。

単に

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

これはおそらくそのファイルのあらゆる種類のリビジョン履歴を殺すと思われるので、それを行うにはかなり醜い方法です...

于 2010-05-04T15:33:38.157 に答える