Dear folks, Over the years, I have been getting weird "checksum error"s when committing changes in certain files.
These ones are NOT related to the common problems of checksum errors with svn, such as corrupted .svn/entries or .svn/text based, or windows xp sp1. Setup: Master on W/xxx Slave and Write-Through-proxy on V/xxx Both are running debian 1.5.1dfsg1- I always use V/xxx. The "expected" checksum in the error cases was the checksum of the file I was trying to commit; while the "actual" was always identical for the same changes, but never the "expected" one. A checkout of the project, and adding the change there always had the same result. It happened with Windows/Tortoise (1.5), Windows/sliksvn (1.5) and Linux/svn 1.6. I finally found out that the problem was related to the write-through-proxy. Using this as key words, I found the following discussions in dev@ and user@ subversion.tigris.org. "bug: mirror WebDAV munging checkins containing "/SVN" " http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363710 http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365481 "write through proxy configuration on windows / apache / svn causing checksum mismatch errors" http://copilotco.com/mail-archives/subversion.2009/msg12009.html It seems that the write-through-proxy code checks the http post to adjust URLs that are different between the proxy and the master. Unfortunately, this is done * for the whole http message * case-insensitively Thus, in any file containing "/XXX/" (in my sample), the XXX is converted into xxx; the checksum on the main server then, correctly, fails. Unfortunately, the XXX in our case is the code for the client we are developing for; and thus, it is also used in, e.g., web service URLs ... until I found out that svn mangles exactly these three letters. Quotes from the links above: Shane Beasley: It seems to be doing a case-insensitive search-and-replace from "remotepath" -- the path component of the master server URI ("/svn" in our case) -- to "localpath" -- apparently the root of the repository as the mirror knows it (also "/svn" in our case). I suspect that it's doing this search-and-replace against the file we're committing, in which case presumably it shouldn't be doing that -- although I'm not sure what it's supposed to be doing instead. David Glasser: This does look pretty nasty. Like, "don't use this feature, it will corrupt your data" nasty. That filter is under-documented; I'm not sure what it's trying to convert. I suppose URLs in the metadata of requests. Justin, this is your code, right? That discussion was two years ago; yet, I have been unable to find a bug/issue report of this problem, or a documented fix. So, before I post the bug report, I ask for feedback here - was the problem observed by others, has it already been fixed in some 1.6.x version, etc. Otherwise, I'll post this as an issue. Thanks, Sebastian
