我在Flex Builder 3中使用子剪辑，最近在尝试提交时收到此错误：

svn：'/ Users / redacted / Documents / Flex Builder 3 / path / to / my / file.mxml'的校验和不匹配；预期：" f8cb275de72776657406154dd3c10348"，实际："空"

我通过以下方法解决了这个问题：

• 提交所有其他更改的文件，省去麻烦的文件。
• 将故障文件的内容复制到TextMate窗口
• 在FlexBuilder / Eclipse中删除我的项目
• 从SVN重新检查我的项目
• 从TextMate窗口中复制故障文件的文本
• 提交更改。

它奏效了，但我不禁认为还有更好的方法。实际导致svn：checksum错误的原因是什么，最好的解决方法是什么。

也许更重要-这是更大问题的征兆吗？

解决方案

回答

.svn目录中的文件，对于该特定文件，它会以某种方式损坏我们已签出的内容，时间，修订版本以及从何处获取的损坏。

这并不比正常的奇数文件问题危险或者严重，它可能是由各种问题引起的，例如，Subversion程序在中间更改时死掉，断电等。

除非它发生更多，否则我不会从中受益匪浅。

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

请注意，如果项目很忙，通常必须合并更改，这可能会导致问题。

例如，我们和同事都签出新副本，然后开始处理同一文件。在某个时候，同事检查他的修改。当我们尝试执行相同的操作时，我们会遇到校验和问题。如果现在复制更改后的文件，请重新签出，那么Subversion将无法跟踪更改应如何合并回去。

如果在这种情况下我们没有遇到问题，那么当我们开始检查修改时，我们将需要先更新工作副本，并可能处理与文件的冲突。

但是，如果我们重新进行结帐，并完成了同事的更改，现在看来我们已删除了他的更改，并用我们自己的更改了。没有冲突，也没有来自颠覆的迹象表明存在问题。

回答

我偶尔会得到类似的结果，通常是几周内没人接近的文件。通常，如果我们知道没有使用过相关目录，则可以删除有问题的目录并运行

svn update

重新创建它。

如果我们在目录中进行了实时更改，则按照lassevk和我们自己的建议，则需要更谨慎的方法。

一般来说，我会说最好不要保留已编辑的文件，并保持工作副本整洁，不要在我们要使用的工作副本中添加大量额外的文件。定期提交，然后如果工作副本变得很混乱，我们可以删除整个内容并重新开始，而不必担心我们可能丢失或者可能丢失的内容，也不必费力找出要保存的文件。

回答

就在今天，我设法通过将损坏目录的副本检出到/ tmp并将该.svn / text-base中的文件替换为刚刚混合的文件来从此错误中恢复。我在博客上详细介绍了该过程。我很想从经验丰富的SVN用户那里听到每种方法的优点和缺点。

回答

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

通常，SVN校验和不匹配意味着不应该更改的文件已经过某种更改。那是什么意思？

• 磁盘损坏(HDD或者IDE电缆损坏)
• 错误的RAM
• 网络链接错误
• 某种后台进程更改了后台文件(恶意软件)

所有这些都是不好的。

但是，我认为问题有所不同。查看错误消息。请注意，它预期会出现一些MD5哈希值，但会返回" null"。如果这是一个简单的文件损坏问题，我希望我们可以为预期/丢失使用两个不同的MD5哈希值。我们拥有" null"这一事实意味着其他问题是错误的。

我有两种理论：

• SVN中的错误。
• 某个文件具有独占锁定，因此无法执行MD5.

如果是＃1，请尝试升级到最新的SVN版本。也许还将其发布在svn-devel邮件列表(http://svn.haxx.se)上，以便开发人员可以看到它。

对于＃2，请检查文件是否被锁定。我们可以下载Process Explorer的副本进行检查。请注意，我们可能想查看谁在文本文件上拥有锁，而不是我们尝试提交的实际文件。

回答

除了错误或者磁盘损坏等以外，还有一个更简单的原因。我认为最可能的原因是有人在工作副本上写了一个递归文本替换，而没有排除.svn文件。
这意味着文件的原始副本(基本上是文件的BASE版本，存储在.svn管理区域中)被修改，并且使MD5和无效。

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

回答

尝试：
svn up --force file.c

这对我有用，而无需执行任何其他操作

回答

遇到了这个问题，我们的开发虚拟机都* nix我们的工作站win32.
一些傻瓜在* nix框上创建了相同名称(不同大小写)的文件
Win32上的所有突然结帐都炸毁了...
因为win不知道与MD5同名的2个文件中的哪个文件，

• nix上的结帐还不错...让我们挠头了一下

通过从具有良好工作副本的* nix框中复制" .svn"文件夹，我能够更新Win框上的仓库。尚未看到回购协议是否可以清理到可以再次进行全面结帐的程度

回答

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

CAVEAT：请确保本地副本是最知名的版本，并且项目中的其他任何人都知道我们在做什么！ (以防万一这还不是很明显)。

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

直接删除的语法：

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

祝你好运！

Ĵ

回答

这是我解决问题v的简单方法，但是按照上面的jsh，需要确保副本是最好的副本。

简单地

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

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