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
Received on 2011-07-19 12:20:13 CEST