修复 SVN 校验和
我在 Flex Builder 3 中使用 subclipse，最近在尝试提交时收到此错误：
svn: '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml' 的校验和不匹配; 预期：'f8cb275de72776657406154dd3c10348'，实际：'null'
我通过以下方式解决了这个问题：
- 提交所有其他更改的文件，忽略麻烦的文件。
- 将故障文件的内容复制到 TextMate 窗口
- 在 FlexBuilder/Eclipse 中删除我的项目
- 从 SVN 中签出新的项目
- 将故障文件的文本从 TextMate 窗口复制回
- 提交更改。
它确实有效，但我忍不住想还有更好的方法。 实际上发生了什么导致 svn:checksum 错误，以及最好的解决方法是什么。
也许更重要的是——这是一个更大问题的征兆吗？
I'm using subclipse in Flex Builder 3, and recently received this error when trying to commit:
svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'
I worked around it by:
- Committing all the other changed files, omitting the troublesome one.
- Copying the contents of the trouble file to a TextMate window
- Deleting my project in FlexBuilder/Eclipse
- Checking my project out fresh from SVN
- Copying the text of the trouble file back in from the TextMate Window
- Committing the changes.
It worked, but I can't help but think there's a better way. What's actaully happening to cause the svn:checksum error, and what's the best fix.
Maybe more important -- is this a symptom of a greater problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（21）
我偶尔会收到类似的东西，通常是几周以来没人接触过的文件。 一般来说，如果您知道自己没有在有问题的目录中工作，则可以删除有问题的目录并运行
以重新创建它。
如果您在目录中进行了实时更改，那么正如 lassevk 和您自己所建议的那样，需要采取更谨慎的方法。
一般来说，我会说最好不要留下未提交的已编辑文件，并保持工作副本整洁 - 不要将一大堆额外的文件添加到您不会使用的工作副本中。 定期提交，然后如果工作副本出现问题，您可以删除整个内容并重新开始，而不必担心您可能会或可能不会丢失什么，也无需费力去弄清楚要保存哪些文件。
I occasionally get similar things, usually with files that nobody has been near in weeks. Generally, if you know you haven't been working in the directory in question, you can just delete the directory with the problem and run
to recreate it.
If you have live changes in the directory then as lassevk and you yourself suggested, a more careful approach is required.
Generally speaking I would say it's a good idea not to leave edited files uncommitted, and keep the working copy tidy - don't add a whole bunch of extra files into the working copy that you aren't going to use. Commit regularly, and then if the working copy goes tits up, you can just delete the whole thing and start over without worrying about what you might or might not be losing, and without the pain of trying to figure out what files to save.
.svn 目录中的文件跟踪您已签出的内容、时间、修订版本以及来源，但该文件已以某种方式损坏。
这并不比正常的奇怪文件问题更危险或更严重，并且可能是由于各种问题造成的，例如颠覆程序在更改过程中死亡、电源中断等。
除非这种情况发生得更多，否则我不会从中赚到太多钱。
可以通过执行您所做的操作来修复它，制作工作文件的副本，签出新副本，然后将修改后的文件添加回来。
请注意，如果您有一个繁忙的项目，而您通常会在其中添加修改后的文件，则这可能会导致问题合并更改。
例如，您和一位同事都签出了一份新副本，并开始处理同一个文件。 在某个时候，你的同事会检查他的修改。 当您尝试执行相同操作时，您会遇到校验和问题。 如果您现在复制更改的文件，重新签出，那么 Subversion 将无法跟踪您的更改应如何合并回来。
如果在这种情况下您没有遇到问题，当您抽出时间签入您的文件时，修改，您需要首先更新您的工作副本，并可能处理与您的文件的冲突。
但是，如果您进行一次新的检查，并完成同事的更改，那么现在看起来您删除了他的更改并用您自己的更改代替。 没有冲突，也没有颠覆的迹象表明有什么问题。
The file in the .svn directory that keeps track of what you have checked out, when, what revision, and from where, has gotten corrupted somehow, for that particular file.
This is no more dangerous or critical than the normal odd file problem, and can be because of various problems, like a subversion program dying mid-change, power-disruption, etc.
Unless it happens more I wouldn't make much out of it.
It can be fixed by doing what you did, make a copy of your work-files, check out a fresh copy, and add the modified files back in.
Note that this might cause problems if you have a busy project where you would normally have to merge in changes.
For instance, you and a collegue both check out a fresh copy, and start working on the same file. At some point, your collegue checks in his modifications. When you attempt to do the same, you get the checksum problem you have. If you now make copies of your changed files, do a fresh checkout, then subversion will lose track of how your changes should be merged back in.
If you didn't get the problem in this case, when you got around to checkin in your modifications, you would need to update your working copy first, and possibly handle a conflict with your file.
However, if you do a fresh checkout, complete with your collegues changes, it now looks like you removed his changes and substituted with your own. No conflicts, and no indications from subversion that something is amiss.
除了错误或磁盘损坏等之外，还有一个更简单的原因。我认为发生这种情况的最可能原因是有人在工作副本上写入递归文本替换，而不排除 .svn 文件。
这意味着文件的原始副本（基本上是文件的 BASE 版本，存储在 .svn 管理区域内）被修改，从而使 MD5 和无效。
@Andrew Hedges：这也解释了为什么你的解决方案解决了这个问题。
There's also a simpler cause for this than just bugs, or disk corruption etc. I think it the most likely cause for this to happen is when someone writes a recursive text replacement on the working copy, without excluding .svn files.
This means the pristine copies of the files (basically the BASE version of the files, that's stored inside the .svn administrative area) get modified, and that invalidates the MD5 sum.
@Andrew Hedges: that also explains why your solution fixes this.
就在今天，我通过将损坏的目录的副本检出到 /tmp 并将 .svn/text-base 中的文件替换为刚刚合并的文件，成功地从这个错误中恢复。 我详细地写了该过程在我的博客上。我很想听听更有经验的 SVN 用户的意见，每种方法的优点和缺点是什么。
Just today, I managed to recover from this error by checking out a copy of the corrupted directory to /tmp and replacing the files in .svn/text-base with the just co'ed ones. I wrote up the procedure in some detail here on my blog. I'd be interested to hear from more experienced SVN users what are the advantages and disadvantages of each approach.
SVN 将您签出的所有文件的原始副本保留在 .svn 目录中。 这称为文本库。 这允许快速差异和恢复。 在各种操作期间，SVN 将对这些基于文本的文件进行校验和以捕获文件损坏问题。
一般来说，SVN 校验和不匹配意味着不应该更改的文件被以某种方式更改了。 这意味着什么？
所有这些都是不好的。
但是，我认为你的问题是不同的。 查看错误消息。 请注意，它需要一些 MD5 哈希值，但返回的是“null”。 如果这是一个简单的文件损坏问题，我预计您将有两个不同的 MD5 哈希值用于预期/得到。 事实上，你有一个“空”意味着其他事情是错误的。
我有两种理论：
对于 #1 的情况，请尝试升级到最新的 SVN 版本。 也许也可以将其发布到 svn-devel 邮件列表 (http://svn.haxx.se)，这样开发者可以看到。
对于#2，请检查是否有任何内容锁定了文件。 您可以下载 Process Explorer 的副本进行检查。 请注意，您可能想查看谁锁定了文本库文件，而不是您尝试提交的实际文件。
SVN keeps pristine copies of all the files you checkout buried in the .svn directories. This is called the text-base. This allows for speedy diffs and reverts. During various operations, SVN will do checksums on these text-base files to catch file corruption issues.
In general, an SVN checksum mismatch means a file that shouldn't have been altered was changed somehow. What does that mean?
All of these are bad.
HOWEVER, I think your problem is different. Look at the error message. Note that it expected some MD5 hashes, but instead got back 'null'. If this were a simple file corruption issue, I would expect that you would have two different MD5 hashes for the expected/got. The fact that you have a 'null' implies that something else is wrong.
I have two theories:
In the case of #1, try upgrading to the latest SVN version. Maybe also post this on the svn-devel mailing list (http://svn.haxx.se), so the developers can see it.
In the case of #2, check to see if anything has the file locked. You can download a copy of Process Explorer to check. Note that you probably want to see who has a lock on the text-base file, not the actual file you were trying to commit.
作为检查新副本（在尝试所有其他选项后我也必须这样做）以及将之前保存的所有更改合并到其中的替代方法，以下方法以相同的方式工作，但为我节省了相当多的钱时间，并可能出现一些错误：
，您应该备份原始损坏的工作副本以防万一。 就我而言，完成后我可以自由地将其删除，因为一切都很顺利。
As an alternative to checking out a fresh copy (which I also had to do after trying all other options) and than merging all your changes which you previously saved backed into it, the following approach worked the same way, but saved me a considerable amount of time, and possibly some errors:
Of course, you should backup your original corrupt working copy just in case. In my case, I was free to remove it after I was done, as everything went fine.
我发现的另一种可能更可怕的校验和冲突解决方法如下：
警告：确保您的本地副本是最知名的版本，并且项目中的其他人都知道您在做什么！ （如果这还不是很明显的话）。
如果您知道该文件的本地副本是“好的”，您可以直接从 SVN 服务器删除该文件，然后强制提交您的本地副本。
直接删除的语法：
祝你好运！
J
Another, possibly even scarier, workaround for checksum conflicts I found is as follows:
CAVEAT: Make sure your local copy is the best known version, AND that anyone else on your project knows what you're doing! (in case this wasn't obvious already).
if you know your local copy of the file is "the good one" you can directly delete the file from the SVN server and then force commit your local copy.
syntax for direct deletion:
good luck!
J
马特，有比您描述的更简单的方法 - 修改 .svn/entries 文件中的校验和。 这是完整的描述：
http:// maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/
Matt, there is easier way than you described - modifying checksum in .svn/entries file. Here is full description:
http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/
我观察到了很多解决方案，从修补 .svn/entries 文件到重新签出。
这可以是一种新的方式（感谢我的同事）：
I've observed a lot of solutions from patching .svn/entries file to fresh checkout.
It can be a new way (thank to my collegue):
尝试：
svn up --force file.c
这对我有用，无需做任何额外的事情
try:
svn up --force file.c
This worked for me without having to do anything extra
当 .svn 文件夹损坏时会发生这种情况。
解决方案：
删除文件包含的整个文件夹并再次检出该文件夹。
This will happens when the .svn folder corrupted.
Solution:
Remove the entire folder of the file contains and checkout the folder again.
遇到这个问题时，我们的开发虚拟机都是 *nix 我们的工作站 win32。
一些傻瓜在 *nix 盒子上创建了同名（不同大小写）的文件
突然间，Win32 上的检查就炸了……
因为win不知道MD5针对的是2个同名文件中的哪一个，
*nix 上的结帐很好...让我们有点摸不着头脑，
我可以通过从 *nix 盒子上复制“.svn”文件夹来更新 win 盒子上的存储库，并提供良好的工作副本。 还没有看到回购是否可以清理到我们可以再次进行完整结账的程度
Had this issue, our dev VM's are all *nix our workstations win32.
some fool(s) created files of the same name (different case) on the *nix box
all of a sudden checkouts on Win32 blows up...
because win doesn't know which of the 2 files of the same name to MD5 against,
checkouts on *nix were fine... leaving us to scratch our heads for a bit
I was able to update the repo on the win box by copying the ".svn" folders over from a *nix box with a good working copy. have yet to see if the repo can be cleaned to the point where we can do a full checkout again
另一种简单的方法...
One other easy way....
.svn\text-base\.svn-base 与签出的文件相同。.svn\entries中的有问题的文件部分（该部分的所有行）与签出的部分相同。.svn\text-base\<problematic file>.svn-baseis identical to one checked out..svn\entriesis identical to one checked out.你不会相信这一点，但我实际上已经通过从我希望签入的有问题的 pom.xml 文件中删除
... 我实际上尝试了所有上述修复此问题的方法，但是无济于事。 我是否遇到过一种非常罕见的情况，即校验和生成器不够强大？
You won't believe this, but I have actually fixed my error by removing the
<scm>...</scm>stance from the offending pom.xml file I was hoping to check in. It contained the URL of the subversion repository it is checked in (this is what the Maven setting is for!), but somehow it generated a faulty checksum for the file while checking in.I literally tried all aforementioned methods of fixing this, but to no avail. Did I encounter a very rare situation in where the checksum generator is not robust enough?
我也偶然发现了这个问题，并试图寻找快速解决方案，尝试了该线程中给出的一些解决方案。
这就是我在开发环境中解决此问题的方法（对我来说这是最小的更改）：
1- 本地删除文件损坏的目录 (WEB-INF)：
2- 从某个目录复制并粘贴目录 (WEB-INF)新鲜签出
3- svn 启动了吗，现在 Eclipse/TortoiseSVN 开始显示此目录中的冲突
4- 将冲突标记为已解决
这有效，我能够更新，提交之前损坏的 web.xml
I also stumbled upon this issue and was trying to look for quick solutions, tried some of the solution given in this thread.
This is how I resolved this issue in my development environment (to me it was minimal change):
1- Locally deleted directory in which the file got corrupted (WEB-INF):
2- Copied and pasted directory (WEB-INF) from a fresh checkout
3- Did svn up, now Eclipse/TortoiseSVN started showing conflict in this directory
4- Marked conflict as Resolved
This worked, I was able to update, commit earlier corrupted web.xml
就我而言，总和是不同的。 我所做的只是：
1）签出到单独的文件夹
2）用 .svn 目录中此文件夹中的文件替换为 svn-client 错误消息中所述的项目问题文件
3）..利润！
In my case the sum was different. All I've done was:
1) Make Check Out to separate folder
2) Replace by file from this folder in .svn directory with my project problem-file which was said in svn-client error message
3) ..Profit!
这是我解决问题的方法 - 很简单，但根据上面的 jsh，需要确保您的副本是最好的。
只需
怀疑这可能会杀死该文件上的各种修订历史记录，所以这是一种非常丑陋的方法......
here's how i fixed the issue - v simple, but as per jsh above, need to be sure your copy is the best one.
simply
suspect this probably kills all sorts of revision history on that file, so it's a pretty ugly way to go about it...
svn update --set-深度空这对我有用。
svn update --set-depth emptyThis work for me.
我在 ubuntu 14.04 上遇到了这个问题，并通过以下步骤解决它：
在这些步骤之后我可以提交文件而不会出现错误。
I had this problem on ubuntu 14.04 and solve it by follow steps:
after these steps i could commit file without error.
虽然这是一个老问题，但我想我也会给出我的 2 美分，因为我刚刚为这个问题苦苦挣扎了一个多小时。
上述解决方案要么对我不起作用，要么看起来过于复杂。
我的解决方案只是从项目中删除所有 svn 文件夹。
<代码>查找 . -name .svn -exec rm -rf {} \;
之后，我再次对项目进行了简单的检查。 因此，我的所有未提交的文件都完好无损，但仍然重建了所有 svn 文件。
Although this is an old issue, I thought I would give my 2 cents as well, since Ive just wrestled with the problem for more than an hour.
The solutions above either didn't work for me, or seemed over-complicated.
My solution was simply to remove all svn folders from the project.
find . -name .svn -exec rm -rf {} \;After this, I did simple checkout of the project again. Thus leaving all my un-committed files intact, but still got a rebuild of all the svn files.