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 将无法跟踪您的更改应该如何合并回来。

如果您在这种情况下没有遇到问题，当您有时间签入您的修改时，您需要先更新您的工作副本，并可能处理与您的文件的冲突。

但是，如果您重新结帐并完成对同事的更改，现在看起来您删除了他的更改并替换为您自己的更改。没有冲突，也没有来自颠覆的迹象表明有什么不对劲。

于 2008-08-08T16:56:13.027 回答
20

除了错误或磁盘损坏等，还有一个更简单的原因。我认为最有可能发生这种情况的原因是有人在工作副本上编写了递归文本替换，而不排除 .svn 文件。
这意味着文件的原始副本（基本上是文件的 BASE 版本，存储在 .svn 管理区域内）被修改，这会使 MD5 和无效。

@Andrew Hedges：这也解释了为什么您的解决方案可以解决此问题。

于 2009-02-23T21:30:14.267 回答
11

SVN 将您签出的所有文件的原始副本保存在 .svn 目录中。这称为文本库。这允许快速的差异和恢复。在各种操作期间，SVN 将对这些基于文本的文件进行校验和，以捕获文件损坏问题。

通常，SVN 校验和不匹配意味着不应该更改的文件以某种方式更改。这意味着什么？

  1. 磁盘损坏（硬盘或 IDE 电缆损坏）
  2. 坏内存
  3. 网络链接不好
  4. 某种后台进程在您背后更改了文件（恶意软件）

所有这些都很糟糕。

但是，我认为您的问题有所不同。查看错误消息。请注意，它需要一些 MD5 散列，但取而代之的是“空”。如果这是一个简单的文件损坏问题，我希望您将有两个不同的 MD5 散列作为预期/得到的。你有一个'null'的事实意味着其他事情是错误的。

我有两个理论：

  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

祝你好运！

Ĵ

于 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

作为检查新副本的替代方法（在尝试所有其他选项后我也必须这样做），而不是将您之前保存的所有更改合并到其中，以下方法以相同的方式工作，但为我节省了大量资金时间，可能还有一些错误：

  1. 查看新的工作副本
  2. 将 .svn 文件夹从您的新副本复制到损坏的副本中
  3. 瞧

当然，您应该备份原始损坏的工作副本以防万一。就我而言，完成后我可以随意删除它，因为一切都很顺利。

于 2013-07-08T16:19:33.803 回答
2

这将在 .svn 文件夹损坏时发生。解决方案：删除文件包含的整个文件夹并再次签出该文件夹。

于 2014-06-12T14:02:53.710 回答
1

有这个问题，我们的开发虚拟机都是 *nix 我们的工作站 win32。一些傻瓜在 *nix 框上创建了同名（不同大小写）的文件突然在 Win32 上的结帐爆炸......因为 win 不知道 MD5 反对的 2 个同名文件中的哪一个，*nix 上的结帐很好......让我们有点摸不着头脑

我可以通过从具有良好工作副本的 *nix 框中复制“.svn”文件夹来更新 win 框上的存储库。还没有看到回购是否可以清理到我们可以再次进行完整结帐的地步

于 2009-07-07T23:14:41.297 回答
1

另一种简单的方法......

  1. 更新您的项目以获取最新版本
  2. 在另一个文件夹中签出相同的版本
  3. 将新结帐中的 .svn 文件夹替换为工作副本（我已替换 .svn-base 文件）
于 2012-01-18T21:30:30.050 回答
0
  1. 仅将具有问题文件的文件夹从存储库检出到其他位置。
  2. 确保.svn\text-base\<problematic file>.svn-base与已签出的相同。
  3. 确保有问题的文件部分（该部分的所有行）与.svn\entries已签出的部分相同。
于 2012-04-24T05:05:14.870 回答
0

你不会相信这一点，但我实际上已经通过<scm>...</scm>从我希望签入的有问题的 pom.xml 文件中删除立场来修复我的错误。它包含它签入的颠覆存储库的 URL（这就是 Maven设置是为了！），但不知何故，它在签入时为文件生成了错误的校验和。

我确实尝试了所有上述解决此问题的方法，但无济于事。我是否遇到过校验和生成器不够健壮的非常罕见的情况？

于 2013-01-10T15:19:09.770 回答
0

我也偶然发现了这个问题，并试图寻找快速的解决方案，尝试了这个线程中给出的一些解决方案。这就是我在我的开发环境中解决这个问题的方法（对我来说这是最小的变化）：

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

于 2013-04-22T07:50:45.917 回答
0

在我的情况下，总和是不同的。我所做的只是：

1) 签出到单独的文件夹

2）用我的项目问题文件替换.svn目录中这个文件夹中的文件，这在svn-client错误消息中说

3) ..利润！

于 2013-05-17T09:03:33.750 回答
0
  1. 转到导致问题的文件夹
  2. 执行命令svn update --set-depth empty
  3. 此文件夹将清空并还原空文件夹
  4. 与 svn 同步并更新。

这对我有用。

于 2013-07-30T10:48:01.427 回答
0

虽然这是一个老问题，但我想我也会给我的 2 美分，因为我已经与这个问题搏斗了一个多小时。

上面的解决方案要么对我不起作用，要么看起来过于复杂。

我的解决方案只是从项目中删除所有 svn 文件夹。

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

在此之后，我再次对项目进行了简单的检查。因此，我所有未提交的文件都完好无损，但仍然重建了所有 svn 文件。

于 2014-07-14T13:22:41.603 回答
0

我在 ubuntu 14.04 上遇到了这个问题，并通过以下步骤解决：

  1. $ cd /var/www/myProject
  2. $ svn升级
  3. $ svn更新

在这些步骤之后，我可以毫无错误地提交文件。

于 2014-08-20T04:37:26.717 回答
-2

这是我解决问题的方法 - v 很简单，但根据上面的 jsh，需要确保您的副本是最好的。

简单地

  1. 复制同一文件夹中的所有问题文件。
  2. 用 svn rm 删除旧的
  3. 犯罪。
  4. 然后将副本重命名为原始文件名。
  5. 再次提交。

怀疑这可能会杀死该文件上的各种修订历史记录，所以这是一种非常丑陋的方法......

于 2010-05-04T15:33:38.157 回答