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.
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
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@
"bug: mirror WebDAV munging checkins containing "/SVN" "
"write through proxy configuration on windows / apache / svn causing
checksum mismatch errors"
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
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:
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.
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.
Received on 2011-07-19 12:20:13 CEST