修复SVN校验和

时间：2008-08-08 16:49:17

标签： svn subclipse

我在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. 复制故障文件的文本
  6. 提交更改。

    7. 它奏效了，但我不禁想到有更好的方法。什么是导致svn：校验和错误，以及什么是最好的解决方案。

    也许更重要 - 这是一个更大问题的症状吗？

21 个答案:

答案 0 :(得分：36)

.svn目录中的文件，用于跟踪您检出的内容，时间，修订版本以及从哪里以某种方式损坏该特定文件。

这并不比普通的奇怪文件问题更危险或更重要，可能是因为各种问题，比如颠覆中期，电源中断等等的颠覆程序。

除非它发生更多，否则我不会做太多的事情。

可以通过执行您的操作来修复，制作工作文件的副本，签出新副本，然后重新添加修改后的文件。

请注意，如果您的繁忙项目通常需要合并更改，则可能会出现问题。

例如，您和同事都签出了新副本，并开始处理同一个文件。在某些时候，你的同事会检查他的修改。当您尝试执行相同操作时，您会遇到校验和问题。如果您现在复制已更改的文件，请进行新的结帐，然后颠覆将失去对您的更改应如何合并的信息。

如果您在这种情况下没有遇到问题，那么当您进行修改时，您需要先更新工作副本，并可能与您的文件发生冲突。

但是，如果您进行了新的结帐，并完成了同事的更改，现在看起来您已删除其更改并替换为您自己的更改。没有冲突，也没有任何迹象表明有些事情是不对的。

答案 1 :(得分：20)

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

@Andrew Hedges：这也解释了为什么你的解决方案解决了这个问题。

答案 2 :(得分：11)

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

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

  1. 磁盘损坏（坏的HDD或IDE电缆）
  2. Bad RAM
  3. 错误的网络链接
  4. 某种后台进程改变了背后的文件（恶意软件）

    5. 所有这些都很糟糕。

    但，我认为您的问题不同了。查看错误消息。请注意，它预计会有一些MD5哈希值，而是返回'null'。如果这是一个简单的文件损坏问题，我希望你有两个不同的MD5哈希值为期望/得到。你有一个'null'的事实意味着其他东西是错误的。

    我有两个理论：

    1. SVN中的错误。
    2. 有些东西对文件有独占锁定，MD5不可能发生。

      3. 对于＃1，请尝试升级到最新的SVN版本。也许也会在svn-devel邮件列表（http://svn.haxx.se）上发布这个帖子，所以开发人员可以看到它。

      在＃2的情况下，检查是否有任何文件被锁定。您可以下载Process Explorer的副本进行检查。请注意，您可能希望查看谁对基于文本的文件具有锁定，而不是您尝试提交的实际文件。

答案 3 :(得分：5)

我偶尔会得到类似的东西，通常是几周内没有人接近过的文件。通常，如果您知道自己没有在相关目录中工作，则可以删除包含该问题的目录并运行

svn update

重新创建它。

如果目录中有实时更改，那么就像你自己建议的那样，需要采取更加谨慎的方法。

一般来说，我会说最好不要保留已编辑的文件，并保持工作副本整洁 - 不要将大量额外文件添加到您不会使用的工作副本中。定期提交，然后如果工作副本出现问题，您可以删除整个事情并重新开始，而不必担心您可能会或可能不会丢失什么，并且没有想要找出要保存的文件的痛苦。< / p>

答案 4 :(得分：5)

就在今天，我设法通过将损坏的目录的副本签出到/ tmp并将.svn / text-base中的文件替换为刚刚执行的文件来设法恢复此错误。我详细编写了程序 here on my blog。我很想听听更有经验的SVN用户对每种方法的优缺点的看法。

答案 5 :(得分：4)

尝试： svn up --force file.c

这对我有用而无需做任何额外的事情

答案 6 :(得分：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

答案 7 :(得分：3)

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

答案 8 :(得分：3)

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

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

如果您知道文件的本地副本是“好的”，您可以直接从SVN服务器删除该文件，然后强制提交本地副本。

直接删除的语法：

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX
祝你好运！

Ĵ

答案 9 :(得分：2)

作为检查新副本的替代方法（在尝试所有其他选项后我也必须执行此操作）并且将您之前保存的所有更改合并到其中，以下方法以相同的方式工作，但保存了我相当长的时间，可能还有一些错误：

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

    4. 当然，您应该备份原始的损坏的工作副本以防万一。在我的情况下，我完成后可以自由删除它，因为一切都很顺利。

答案 10 :(得分：2)

当.svn文件夹损坏时会发生这种情况。 解： 删除文件包含的整个文件夹，然后再次签出该文件夹。

答案 11 :(得分：1)

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

我能够通过从具有良好工作副本的* nix框复制“.svn”文件夹来更新win框上的repo。还没有看到回购可以清理到我们可以再次完全结账

答案 12 :(得分：1)

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

  1. 更新您的项目以获取最新版本
  2. 在其他文件夹中签出相同版本
  3. 将新结帐时的.svn文件夹替换为工作副本（我已替换.svn-base文件）

答案 13 :(得分：0)

  1. 仅查看存储库中存在问题文件的文件夹到其他位置。
  2. 确保.svn\text-base\<problematic file>.svn-base与签出的相同。
  3. 确保.svn\entries中有问题的文件部分（该部分的所有行）与签出的部分相同。

答案 14 :(得分：0)

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

我真的尝试了所有上述方法来解决这个问题，但无济于事。在校验和生成器不够健壮的情况下，我遇到过一种非常罕见的情况吗？

答案 15 :(得分：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

答案 16 :(得分：0)

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

1）勾选以分隔文件夹

2）使用我的项目问题文件替换.svn目录下此文件夹中的文件，该文件在svn-client错误消息中说明

3）..Profit！

答案 17 :(得分：0)

  1. 转到导致问题的文件夹
  2. 执行命令svn update --set-depth empty
  3. 此文件夹将清空并还原空文件夹
  4. 与svn同步并更新。

    5. 这项工作适合我。

答案 18 :(得分：0)

虽然这是一个老问题，但我认为我也会给我2美分，因为我刚刚解决了这个问题一个多小时。

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

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

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

在此之后，我再次对项目进行了简单的检查。因此，保留所有未提交的文件，但仍然可以重建所有svn文件。

答案 19 :(得分：0)

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

  1. $ cd / var / www / myProject
  2. $ svn upgrade
  3. $ svn update

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

答案 20 :(得分：-2)

这是我如何解决问题 - 简单，但按照上面的jsh，需要确保你的副本是最好的。

简单地

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

    6. 怀疑这可能会杀死该文件上的各种修订历史记录，所以这是一个非常难看的方式...

相关问题
最新问题