[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Checksum mismatch commit 1.6.9

From: Bert Huijben <bert_at_vmoo.com>
Date: Wed, 25 Aug 2010 14:28:39 +0200

> -----Original Message-----
> From: Andersen, Krista [mailto:Krista.Andersen_at_itg.com]
> Sent: woensdag 25 augustus 2010 1:39
> To: users_at_subversion.apache.org
> Subject: Checksum mismatch commit 1.6.9
> Hi all,
> Today I found a situation where the "expected" checksum value from a
> checksum mismatch error message was not in the .svn/entries file.
> However, there was a third and completely different value instead (-it did
> not match the "actual" checksum value either). When I replaced that
> checksum value in the .svn/entries file with the "actual" value, I still
> a checksum error.
> (Usually, if nothing is obviously wrong with the file that is generating
> checksum error on commit, then I replace the 'expected' checksum value in
> the .svn/entries file with the 'actual' checksum value from the error
> output. I save these changes to .svn/entries and commit to the offending
> file without error... I am referring to the .svn folder that resides in
the same
> folder as the file that generated the checksum error on commit.)
> This did not work today. The fix that finally did work:
> 1. I checked out a working copy (that included the offending file) onto my
> desktop. I added a comment to the offending file and committed my
> change.
> 2. The developer that was seeing the Checksum error message was able to
> update to get my changes, delete my changes and successfully commit this.
> 3. When he tried to add the actual edits he wanted back into that file ,
> same checksum error returned on commit.
> 4. So I added the developers (uncommitted) changes in my working copy,
> and I committed without error.
> 5. The developer was then able to update to get the file as he wanted it.
> We have 1.6.9 on our servers.
> And 1.6.7 as our TortoiseSVN clients.
> The file was a txt file with extension .exe.config and was 9K in size.
> He was using Visual Studio 2008 to edit the file, I used Notepad++.
> Does anyone know what can cause this type of checksum error?
> Can we prevent it somehow?
> Why did the "expected" and "actual" checksum values in the error message
> output *not* match the "third" Checksum value in the .svn/entries file?

I don't know the exact details, but you might get in this situation when the
so called 'wc-props' or as we call them in WC-NG 'dav properties' are out of
sync with the http/https based repository. These values are cached in

The expected checksum verified on a commit is the checksum of the local
(BASE) version compared to the HEAD revision in the repository. Most likely
the local version was an older version of the same file, which didn't get
updated properly because the wcprops were out of sync (So the 'svn update'
step failed for you).

Deleting the all-wcprops file should be safe to resolve these issues. (As
things look now, we recommend running svn cleanup in 1.7 as this cache moves
in the db)

I would never change the checksum in the entries file, as it generally just
makes Subversion think that files are the same while they actually aren't:
Not something I would like to use as the base for a commit that shouldn't
(The checksum in .svn/entries should always match the MD5 of the checksum of
the file in .svn/text-base.. If not there is some serious issue)


> Thank you,
> Krista
Received on 2010-08-25 14:29:57 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.