修复SVN校验和

我在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. 提交更改。

它的工作，但我不禁觉得有一个更好的办法。 什么是actaully发生导致svn：checksum错误，什么是最好的修复。

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

Answer 1

.svn目录中的文件，用于跟踪您已经检出的内容，何时修改以及从哪里修改特定文件。

这并不比正常的奇怪文件问题更危险或者更危险，而且可能是因为各种问题，比如颠覆中断，电源中断等等。

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

它可以通过做你做的事情来修复，复制你的工作文件，签出新的副本，并添加修改后的文件。

请注意，这可能会导致问题，如果你有一个繁忙的项目，你通常需要合并变化。

例如，你和一个同事都检出一个新的副本，并开始在同一个文件上工作。 在某个时候，你的同事检查他的修改。 当你试图做同样的事情时，你会得到你有的校验和问题。 如果您现在制作了更改后的文件的副本，请执行全新的结帐操作，然后颠覆操作将无法跟踪您的更改应该如何重新合并。

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

但是，如果您进行全新的结帐，请完成您的同事更改，现在看起来您已经取消了自己的更改并取而代之。 没有冲突，也没有颠覆的迹象表明有什么不妥之处。

Answer 2

还有一个更简单的原因，不仅仅是错误或磁盘损坏等。我认为这最可能发生的原因是有人在工作副本上写入recursion文本replace，而不排除.svn文件。
这意味着文件的原始副本（基本上是存储在.svnpipe理区域内的文件的BASE版本）被修改，并且使MD5总和无效。

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

Answer 3

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

一般来说，SVN校验和不匹配意味着一个不应该被改变的文件被以某种方式改变。 那是什么意思？

1. 磁盘损坏（坏的硬盘或IDE电缆）
2. 糟糕的RAM
3. 坏的networking链接
4. 某种后台进程改变了背后的文件（恶意软件）

所有这些都不好。

不过 ，我认为你的问题是不一样的。 看看错误信息。 请注意，它期望一些MD5散列，但取而代之的是“空”。 如果这是一个简单的文件损坏问题，我希望你会有两个不同的MD5散列预期/得到。 你有一个“空”的事实意味着别的是错的。

我有两个理论：

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

在＃1的情况下，请尝试升级到最新的SVN版本。 也许还可以在svn-devel邮件列表（ http://svn.haxx.se ）上发布，所以开发人员可以看到它。

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

Answer 4

我偶尔会得到类似的东西，通常是几个星期内没有人接近的文件。 一般来说，如果你知道你没有在目录中工作，你可以删除问题目录并运行

 svn update 

重新创build它。

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

一般来说，我会说这是一个好主意，不要留下编辑的文件未提交，并保持工作副本整洁 – 不要将一大堆额外的文件添加到您不打算使用的工作副本。 定期提交，然后如果工作副本出现问题，你可以删除整个事情，重新开始，而不用担心你可能会或可能不会丢失什么，也没有试图弄清楚什么文件要保存的痛苦。

Answer 5

就在今天，我设法通过检出损坏目录的副本到/ tmp并用.svn / text-base文件replace刚才的同名文件来恢复这个错误。 我在博客上详细地写下了这个程序。 我有兴趣从更有经验的SVN用户那里听说每种方法的优点和缺点。

Answer 6

试试：svn up –force file.c

这对我来说没有任何额外的工作

Answer 7

我已经观察了很多从修补.svn / entries文件到新鲜结帐的解决scheme。

这可能是一种新的方式（感谢我的同事）：

 - 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

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

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

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

直接删除的语法：

svn delete -m“删除损坏的文件XXXX”svn + ssh：// username @ svnserver / path / to / XXXX

祝你好运！

Ĵ

Answer 9

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

Answer 10

有这个问题，我们的开发虚拟机都是* nix我们的工作站win32。 一些傻瓜在* nix盒子上创build了相同名称（不同情况）的文件，所有突然在Win32上签出的结果都被炸毁了…因为win不知道同一个名字的两个文件中的哪一个到MD5 ，在* nix的结帐罚款…留下我们的脑袋，一点点

我能够通过复制“.svn”文件夹从一个好的工作副本的* nix框中更新win框的回购。 还没有看到回购可以清理到我们可以再次全面结帐的地步

Answer 11

另一个简单的方法….

1. 更新您的项目以获取最新版本
2. 在其他文件夹中签出相同的版本
3. 从新的签出replace.svn文件夹到工作副本（我已经replace.svn基文件）

Answer 12

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

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

当然，你应该备份你原来的腐败工作副本，以防万一。 就我而言，完成后我可以自由地将其删除，因为一切正常。

Answer 13

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

Answer 14

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

Answer 15

你不会相信这一点，但我实际上已经解决了我的错误，从我希望检查的有问题的pom.xml文件中删除<scm>...</scm>立场。它包含了Subversion版本库的URL它被签入（这是Maven设置的目的！），但是它在签入时却以某种方式为文件生成了错误的校验和。

我从字面上试图解决这个问题的所有上述方法，但无济于事。 在校验和生成器不够强大的情况下，我遇到了一个非常罕见的情况吗？

Answer 16

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

1-本地删除文件被损坏的目录（WEB-INF）：

  svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml': expected: d60cb051162e4a6790a3ea0c9ddfb434 actual: 16885ded2cbc1adc250e4cbbc1427546 

2-从新的结帐复制并粘贴目录（WEB-INF）

svn了，现在Eclipse / TortoiseSVN开始在这个目录中显示冲突

4-已解决标记的冲突

这工作，我能够更新，提交早期损坏的web.xml

Answer 17

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

1）进行检查分离文件夹

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

3）利润！

Answer 18

1）转到导致问题的文件夹2）执行命令svn update –set-depth empty 3）该文件夹将清空并恢复空文件夹。 4）与svn同步并更新。

这为我工作。

Answer 19

虽然这是一个老问题，但我还是愿意给我2分钱，因为我刚刚解决了这个问题一个多小时。

上面的解决scheme对我来说都不起作用，或者看起来过于复杂。

我的解决scheme是简单地从项目中删除所有svn文件夹。

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

在此之后，我再次做了简单的项目结账。 因此，我的所有未提交的文件保持完好，但仍然得到了所有svn文件的重build。

Answer 20

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

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

经过这些步骤，我可以提交文件没有错误。

Answer 21

这里是我如何解决这个问题 – v简单，但根据上面的jsh，需要确保你的副本是最好的。

只是

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

怀疑这可能会杀死该文件的各种修订历史，所以这是一个相当丑陋的方式去做…