我在Flex Builder 3中使用了subclipse，最近在尝试提交时收到了这个错误：
svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'
我解决了以下问题：
它奏效了，但我不禁想到有更好的方法。导致svn：checksum错误的实际情况是什么，以及最好的修复方法。
也许更重要的是 - 这是一个更大问题的症状吗？
.svn目录中的文件，用于跟踪您检出的内容，时间，修订版本以及从哪里以某种方式损坏该特定文件。
这并不比正常的奇怪文件问题更危险或更关键，并且可能是由于各种问题，例如颠覆中期变更，电源中断等等。
除非它发生更多，否则我不会做太多。
可以通过执行您所做的操作来修复，制作工作文件的副本，签出新副本，然后重新添加修改后的文件。
请注意，如果您有一个繁忙的项目，通常必须在更改中合并，这可能会导致问题。
例如，您和同事都签出了一份新副本，并开始处理同一个文件。在某些时候，你的同事会检查他的修改。当您尝试执行相同操作时，您会遇到校验和问题。如果您现在复制已更改的文件，请进行新的结帐，然后颠覆将失去对您的更改应如何合并的信息。
如果您在这种情况下没有遇到问题，那么当您需要检查修改时，您需要先更新工作副本，并可能与您的文件发生冲突。
但是，如果您进行了新的结帐，并完成了同事的更改，现在看起来您已删除其更改并替换为您自己的更改。没有冲突，也没有任何迹象表明有些事情是不对的。
作为检查新副本的替代方法（在尝试所有其他选项后我也必须执行此操作）并且将之前保存的所有更改合并到其中，以下方法的工作方式相同，但为我节省了相当多的费用时间，可能还有一些错误：
当然，您应该备份原始的损坏的工作副本以防万一。在我的情况下，我完成后可以自由删除它，因为一切都很顺利。
当.svn文件夹损坏时会发生这种情况。解决方案：删除文件包含的整个文件夹，然后再次签出该文件夹。
如果有这个问题，我们的开发虚拟机就是我们的工作站win32。一些傻瓜在* nix框上创建了相同名称的文件（不同的情况），Win32上的所有突然检查都爆炸了......因为win不知道MD5中同名的2个文件中的哪一个，* nix上的结账很好......让我们抓住我们的头
我能够通过从具有良好工作副本的* nix框复制“.svn”文件夹来更新win框上的repo。还没有看到回购可以清理到我们可以再次完全结账的程度
另一个简单的方法....
.svn\text-base\<problematic file>.svn-base与签出的相同。.svn\entries中有问题的文件部分（该部分的所有行）与签出的部分相同。你不会相信这一点，但我实际上通过从我希望检入的有问题的pom.xml文件中删除<scm>...</scm>站点来修复我的错误。它包含检查的subversion存储库的URL（这就是Maven设置适用于！），但不知何故，它在检入时为文件生成了错误的校验和。
我确实尝试了所有上述方法来解决这个问题，但无济于事。在校验和生成器不够健壮的情况下，我遇到过一种非常罕见的情况吗？
我也偶然发现了这个问题，并试图寻找快速的解决方案，尝试了这个线程中给出的一些解决方案。这就是我在开发环境中解决这个问题的方法（对我来说这是最小的改变）：
1-本地删除的文件已损坏的目录（WEB-INF）：
svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
expected: d60cb051162e4a6790a3ea0c9ddfb434
actual: 16885ded2cbc1adc250e4cbbc1427546
2-从新结账处复制并粘贴目录（WEB-INF）
3- svn up，现在Eclipse / TortoiseSVN开始在这个目录中显示冲突
4-已标记的冲突已解决
这工作，我能够更新，提交早期损坏的web.xml
就我而言，总和是不同的。我所做的就是：
1）勾选以分隔文件夹
2）使用我的项目问题文件替换.svn目录中此文件夹中的文件，该文件在svn-client错误消息中说
3）..Profit！
虽然这是一个老问题，我想我也会给我2美分，因为我刚刚解决了这个问题超过一个小时。
上面的解决方案对我来说不起作用，或者看起来过于复杂。
我的解决方案只是从项目中删除所有svn文件夹。
find . -name .svn -exec rm -rf {} \;
在此之后，我再次对项目进行了简单的检查。因此，保留所有未提交的文件，但仍然可以重建所有svn文件。
我在ubuntu 14.04上遇到了这个问题，并按照以下步骤解决：
在这些步骤之后，我可以无错误地提交文件。
还有一个更简单的原因，而不仅仅是错误或磁盘损坏等。我认为最有可能发生这种情况的原因是有人在工作副本上写了递归文本替换，而不排除.svn文件。 这意味着文件的原始副本（基本上是文件的BASE版本，存储在.svn管理区域内）会被修改，并使MD5总和无效。
@Andrew Hedges：这也解释了为什么你的解决方案解决了这个问题。
svn update --set-depth empty这对我有用。
这是我如何解决问题 - 简单，但按照上面的jsh，需要确保你的副本是最好的。
只是
怀疑这可能会杀死该档案的各种修订历史，所以这是一个非常难看的方式......
SVN保留您在.svn目录中隐藏的所有文件的原始副本。这称为文本库。这允许快速差异和恢复。在各种操作中，SVN将对这些基于文本的文件执行校验和以捕获文件损坏问题。
通常，SVN校验和不匹配意味着不应该以某种方式更改不应更改的文件。那是什么意思？
所有这些都很糟糕。
但是，我认为你的问题是不同的。查看错误消息。请注意，它预计会有一些MD5哈希值，而是返回'null'。如果这是一个简单的文件损坏问题，我希望你有两个不同的MD5哈希值为期望/得到。你有一个'null'的事实意味着其他东西是错的。
我有两个理论：
在＃1的情况下，尝试升级到最新的SVN版本。也许也发布在svn-devel邮件列表（http://svn.haxx.se）上，所以开发人员可以看到它。
在＃2的情况下，检查是否有任何文件被锁定。您可以下载Process Explorer的副本进行检查。请注意，您可能希望查看谁对文本库文件具有锁定，而不是您尝试提交的实际文件。
我偶尔会得到类似的东西，通常是几周内没有人接近的文件。通常，如果您知道自己没有在相关目录中工作，则只需删除包含问题的目录并运行即可
svn update
重新创建它。
如果你在目录中有实时更改，那么就像你自己建议的那样，需要采取更加谨慎的方法。
一般来说，我会说最好不要保留已编辑的文件，并保持工作副本整洁 - 不要将大量额外文件添加到您不会使用的工作副本中。定期提交，然后如果工作副本出现问题，您可以删除整个事情并重新开始，而不必担心您可能会或可能不会丢失什么，并且没有试图找出要保存的文件的痛苦。
就在今天，我设法通过将损坏的目录的副本签出到/ tmp并将.svn / text-base中的文件替换为刚刚执行的文件来设法恢复此错误。我在一些细节here on my blog写了这个程序。我很想知道更有经验的SVN用户，每种方法的优点和缺点是什么。
尝试：svn up --force file.c
这对我有用而无需做任何额外的事情
我已经观察了很多解决方案，从.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
Matt，有比你描述的更简单的方法 - 修改.svn / entries文件中的校验和。这是完整的描述：http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/
我发现校验和冲突的另一个可能更可怕的解决方法如下：
CAVEAT：确保您的本地副本是最知名的版本，并且项目中的任何其他人都知道您在做什么！ （如果这不是很明显）。
如果您知道该文件的本地副本是“好的”，您可以直接从SVN服务器中删除该文件，然后强制提交本地副本。
直接删除的语法：
svn delete -m "deleting corrupted file XXXX"
svn+ssh://username@svnserver/path/to/XXXX
祝好运！
Ĵ