关于子剪辑：修复SVN校验和

我在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程序死于中间更改，电源中断等。

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

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

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

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

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

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

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

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

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

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

所有这些都是不好的。

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

我有两种理论：

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

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

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

重新创建它。

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

总的来说，我想说一个好主意是不要使未编辑的文件处于未提交状态，并保持工作副本整齐-不要在工作副本中添加大量多余的文件，而这些文件将不再使用。定期提交，然后如果工作副本变得很混乱，您可以删除整个内容并重新开始，而不必担心您可能丢失或可能丢失的内容，也不必费力找出要保存的文件。

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

从修补.svn / entries文件到重新签出，我已经观察到许多解决方案。

这可能是一种新方法(感谢我的同事)：

尝试：
svn up --force file.c

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

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

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

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

直接删除的语法：

祝好运！

?

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

作为签出新副本的替代方法(尝试所有其他选项之后我也必须这样做)，而不是合并之前保存的所有更改，以下方法以相同的方式工作，但为我节省了很多时间，可能还有一些错误：

当然，您应该备份原始的损坏的工作副本，以防万一。就我而言，由于一切正常，我可以在完成后自由删除它。

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

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

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

另一种简单的方法。

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

经过这些步骤，我可以提交文件而不会出现错误。

您不会相信这一点，但实际上通过从我希望检入的有问题的pom.xml文件中删除了...立场，实际上已经解决了我的错误。该文件包含要检入的subversion存储库的URL(这是Maven设置的目的！)，但是在签入时却以某种方式为文件生成了错误的校验和。

我确实尝试了所有上述修复此问题的方法，但均无济于事。在校验和生成器不够强大的情况下，我是否遇到过非常罕见的情况？

我也偶然发现了这个问题，并试图寻找快速的解决方案，并尝试了该线程中给出的一些解决方案。
这就是我在开发环境中解决此问题的方式(对我来说，这是最小的更改)：

1-文件被破坏的本地删除目录(WEB-INF)：

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文件。

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

只是

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