修复 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 文件。
这意味着文件的原始副本（基本上是文件的 BASE 版本，存储在 .svn 管理区域内）被修改，从而使 MD5 和无效。

@安德鲁·赫奇斯：这也解释了为什么您的解决方案可以解决此问题。

Answer 3

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

一般来说，SVN 校验和不匹配意味着不应该更改的文件被以某种方式更改了。这意味着什么？

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

所有这些都是不好的。

然而, ，我认为你的问题是不同的。查看错误消息。请注意，它需要一些 MD5 哈希值，但返回的是“null”。如果这是一个简单的文件损坏问题，我预计您将有两个不同的 MD5 哈希值用于预期/得到。事实上，你有一个“空”意味着还有其他问题。

我有两个理论：

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

马特，有比您描述的更简单的方法 - 修改 .svn/entries 文件中的校验和。这是完整的描述：http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

我发现的另一种可能更可怕的校验和冲突解决方法如下：

警告： 确保您的本地副本是最知名的版本，并且项目中的其他人都知道您在做什么！（如果这还不是很明显的话）。

如果您知道该文件的本地副本是“好的”，您可以直接从 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

遇到这个问题时，我们的开发虚拟机都是 *nix 我们的工作站 win32。一些傻瓜在 *nix框上创建了同名文件（不同情况）的文件，win32上的所有结帐均突然结帐...因为Win不知道MD5的同名两个文件中的哪个文件中的哪个文件，所以 *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-client 错误消息中所说的我的项目问题文件替换 .svn 目录中此文件夹中的文件

3）..利润！

Answer 18

虽然这是一个老问题，但我想我也会给出我的 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. 再次提交。

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