修复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错误,什么是最好的修复。

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

21 Solutions collect form web for “修复SVN校验和”

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

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

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

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

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

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

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

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

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

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

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的副本进行检查。 请注意,您可能希望查看谁在文本库文件上有锁,而不是您要提交的实际文件。

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

 svn update 

重新创build它。

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

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

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

试试:svn up –force file.c

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

我已经观察了很多从修补.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 

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

CAVEAT:确保您的本地副本是最知名的版本,并且项目中的其他人知道您在做什么! (如果这不是很明显)。

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

直接删除的语法:

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

祝你好运!

Ĵ

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

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

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

另一个简单的方法….

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

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

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

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

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

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

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

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

我也偶然发现这个问题,并试图寻找快速解决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

在我的情况下,总数是不同的。 我所做的只是:

1)进行检查分离文件夹

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

3)利润!

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

这为我工作。

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

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

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

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

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

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

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

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

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

只是

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

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

  • 什么是工作副本,什么是“切换”为我在龟龟SVN做?
  • 在提交之前“取消”添加一个文件到svn
  • 使用SVN比CVS有什么优势?
  • Subversion:如何find没有合并到中继的所有修订?
  • 通过命令行使用TortoiseSVN
  • 什么使DVCS合并变得容易?
  • Subversion vs CVS
  • 在DropBox中使用Subversion
  • 是否有可能链接SVN库文件,以便文件实际上是另一个库文件的引用?
  • 合并:汞/ Git与SVN
  • 如何在开发,testing和生产中pipe理数据库?