我在 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 目录中的文件，用于记录您已签出的内容、时间、修订版本以及从何处以某种方式损坏，对于该特定文件。
这并不比正常的奇怪文件问题更危险或更严重，并且可能是由于各种问题，例如颠覆程序在更改中死亡、电源中断等。
除非它发生更多，否则我不会从中获利。
可以通过执行您所做的操作来修复它，复制您的工作文件，签出新副本，然后重新添加修改后的文件。
请注意，如果您有一个繁忙的项目，通常必须合并更改，这可能会导致问题。
例如，您和一位同事都签出一份新副本，然后开始处理同一个文件。在某个时候，您的同事会检查他的修改。当您尝试这样做时，您会遇到校验和问题。如果您现在复制更改的文件，重新签出，那么 subversion 将无法跟踪您的更改应该如何重新合并。
如果您在这种情况下没有遇到问题，当您有时间签入您的修改时，您需要先更新您的工作副本，并可能处理与您的文件的冲突。
但是，如果您重新结帐并完成对同事的更改，现在看起来您删除了他的更改并替换为您自己的更改。没有冲突，也没有来自颠覆的迹象表明有什么不对劲。
【讨论】：
除了错误或磁盘损坏等之外，还有一个更简单的原因。我认为最有可能发生这种情况的原因是有人在工作副本上编写了递归文本替换，而不排除 .svn 文件。 这意味着文件的原始副本（基本上是文件的 BASE 版本，存储在 .svn 管理区域内）被修改，这会使 MD5 和无效。
@Andrew Hedges：这也解释了为什么您的解决方案可以解决此问题。
【讨论】：
SVN 将您签出的所有文件的原始副本保存在 .svn 目录中。这称为文本库。这允许快速的差异和恢复。在各种操作过程中，SVN 将对这些基于文本的文件进行校验和，以发现文件损坏问题。
通常，SVN 校验和不匹配意味着不应该更改的文件以某种方式更改。这是什么意思？
所有这些都是坏的。
但是，我认为您的问题有所不同。查看错误消息。请注意，它需要一些 MD5 散列，但取而代之的是“空”。如果这是一个简单的文件损坏问题，我希望您将有两个不同的 MD5 散列作为预期/得到的。你有一个'null'的事实意味着其他事情是错误的。
我有两个理论：
在#1的情况下，尝试升级到最新的SVN版本。或许也可以将其发布到 svn-devel 邮件列表 (http://svn.haxx.se)，以便开发人员看到。
在 #2 的情况下，检查文件是否被锁定。您可以下载 Process Explorer 的副本进行检查。请注意，您可能想查看谁锁定了 text-base 文件，而不是您尝试提交的实际文件。
【讨论】：
就在今天，我通过将损坏目录的副本检出到 /tmp 并将 .svn/text-base 中的文件替换为刚刚合并的文件，设法从这个错误中恢复过来。我详细地编写了该过程here on my blog。我很想听听更有经验的 SVN 用户的意见，每种方法的优缺点是什么。
【讨论】：
我偶尔会收到类似的东西，通常是几周内没人靠近过的文件。一般来说，如果你知道你没有在有问题的目录中工作，你可以删除有问题的目录并运行
svn update
重新创建它。
如果您在目录中有实时更改，那么您自己建议的 lassevk，则需要更谨慎的方法。
一般来说，我会说最好不要留下未提交的已编辑文件，并保持工作副本整洁 - 不要将一大堆额外文件添加到您不会使用的工作副本中。定期提交，然后如果工作副本出现问题，您可以删除整个内容并重新开始，而不必担心您可能会丢失或可能不会丢失什么，也无需尝试找出要保存哪些文件的痛苦。
【讨论】：
尝试： 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
【讨论】：
马特，有比你描述的更简单的方法 - 修改 .svn/entries 文件中的校验和。这是完整的描述： http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/
【讨论】：
我发现的另一个可能更可怕的校验和冲突解决方法如下：
警告：确保您的本地副本是最知名的版本，并且您项目中的其他任何人都知道您在做什么！ （以防这还不是很明显）。
如果您知道该文件的本地副本是“好的”，您可以直接从 SVN 服务器中删除该文件，然后强制提交您的本地副本。
直接删除的语法：
svn delete -m "deleting corrupted file XXXX"
svn+ssh://username@svnserver/path/to/XXXX
祝你好运！
J
【讨论】：
作为检查新副本的替代方法（在尝试所有其他选项后我也必须这样做），而不是将之前保存的所有更改合并到其中，以下方法的工作方式相同，但救了我相当长的时间，可能还有一些错误：
当然，您应该备份损坏的原始工作副本以防万一。就我而言，完成后我可以随意删除它，因为一切都很好。
【讨论】：
当 .svn 文件夹损坏时会发生这种情况。 解决方案： 删除文件包含的整个文件夹并再次签出该文件夹。
【讨论】：
有这个问题，我们的开发虚拟机都是 *nix 我们的工作站 win32。 一些傻瓜在 *nix 盒子上创建了同名（不同大小写）的文件 Win32上的结帐突然爆炸了... 因为win不知道MD5针对的2个同名文件中的哪一个， *nix 上的结帐很好……让我们有点摸不着头脑
我能够通过从具有良好工作副本的 *nix 框复制“.svn”文件夹来更新 win 框上的 repo。还没有看到是否可以将 repo 清理到我们可以再次进行完整结帐的地步
【讨论】：
另一种简单的方法....
【讨论】：
.svn\text-base\<problematic file>.svn-base 与已签出的相同。.svn\entries 中的问题文件部分（该部分的所有行） 与已签出的部分相同。【讨论】：
你不会相信这一点，但实际上我已经通过从我希望签入的有问题的 pom.xml 文件中删除 <scm>...</scm> 立场来修复我的错误。它包含它签入的颠覆存储库的 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 启动了，现在 Eclipse/TortoiseSVN 开始在这个目录中显示冲突
4- 将冲突标记为已解决
这行得通，我能够更新、提交早期损坏的 web.xml
【讨论】：
在我的情况下，总和是不同的。我所做的只是：
1) 签出到单独的文件夹
2) 将 .svn 目录中此文件夹中的文件替换为我在 svn-client 错误消息中所述的项目问题文件
3) ..利润！
【讨论】：
虽然这是一个老问题，但我想我也会给我的 2 美分，因为我刚刚与这个问题搏斗了一个多小时。
上述解决方案要么对我不起作用，要么看起来过于复杂。
我的解决方案只是从项目中删除所有 svn 文件夹。
find . -name .svn -exec rm -rf {} \;
在此之后，我再次对项目进行了简单的检查。因此，我所有未提交的文件都完好无损，但仍然重建了所有 svn 文件。
【讨论】：
我在 ubuntu 14.04 上遇到了这个问题，按照以下步骤解决：
在这些步骤之后，我可以毫无错误地提交文件。
【讨论】：
svn update --set-depth empty
这对我有用。
【讨论】：
这是我解决问题的方法 - v 很简单，但根据上面的 jsh，需要确保您的副本是最好的。
简单
怀疑这可能会杀死该文件的各种修订历史记录，所以这是一种非常丑陋的处理方式......
【讨论】：