修复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:校验和错误,以及什么是最好的解决方案.

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

Answer 1

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

这并不比正常的奇数文件问题更危险或更关键,并且可能是由于各种问题,如颠覆程序中途死亡,电源中断等.

除非它发生更多,否则我不会做太多.

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

请注意,如果您有一个繁忙的项目,通常必须在更改中合并,这可能会导致问题.

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

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

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

Answer 2

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

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

Answer 3

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

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

1. 磁盘损坏(坏的HDD或IDE电缆)
2. 糟糕的内存
3. 网络链接不好
4. 某种后台进程改变了你背后的文件(恶意软件)

所有这些都很糟糕.

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

我有两个理论:

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

在#1的情况下,尝试升级到最新的SVN版本.也许也可以在svn-devel邮件列表(http://svn.haxx.se)上发布,所以开发人员可以看到它.

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

Answer 4

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

svn update

重新创建它.

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

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

Answer 5

就在今天,我设法通过将损坏的目录的副本签出到/ tmp并将.svn/text-base中的文件替换为刚刚执行的文件来设法恢复此错误.我在博客上详细介绍了这个程序.我很想知道更有经验的SVN用户,每种方法的优点和缺点是什么.