Subversion Commit Problem: XML data was not well-formed

Question

I'm experiencing a strange behavior of SVN. I've got SVN repository running on Apache 2.2.9 with mod_dav, mod_dav_svn and SVN 1.5.2. When I try to check out (from remote 1.5.4 client or server-local 1.5.2 client - both "default" svn binaries), I'm getting something like:

mx-mac:Test mx$ svn ci -m "" Adding test.txt svn: Commit failed (details follow): svn: XML data was not well-formed

What I've found out by sniffing the HTTP connection is, that one request to remote SVN repository (Apache) ends by "Reset by peer" and not returning the response (used HTTP Scoop to sniff).

As for the configuration of Apache, all modules are loaded. Proper permissions are set for repo and repo was created by svnadmin create and then chowned to apache user (anyway, it did not worked even if I've chmod -R 777 repo directory).

Apache configuration contains DAV and SVNPath directives along with authentication.

I'm pretty desperate after few long hours of trying, so if someone ever encountered such issue, please let me know. Thanks a lot!

Answer 1

The best way on how to get an answer is to ask and then think. I did,... at last, I've found, that redefined ErrorDocument in .htaccess file for the same VirtualHost as the SVN's caused invalid data to be sent to SVN client on some occasions and for some reason intercepting with commit process.

Answer 2

While in theory it would be educational to figure out problems like this, life is too short and i'm already expert at other things, for which i'm being paid to be expert at, so my fallback solution to any svn trouble is this: go outside of the working copy, make a new directory somewhere else, make a fresh checkout of whatever branch from the repository, and then manually update the files you know you've changed, by copying from the messed-up checkout.

As for apache, i'd bet it's innocent of any trouble. Failed commits are almost always due to something other than the connection to the repository. (Assuming no one was tinkering with apache or the svn server.) No guarantee, but trying the fresh-checkout and manual copying over of files may just work, or at least reveal new diagnostic information.

Answer 3

Daren, you are not exactly correct right now. I've tried all the possible combinations of working copies, new repositories and so on. I've tried mostly everything. At last, I've found one strange message in NEON debug messages, displaying my 404 page on a homepage, which I mostly forgot about. Then, I've realized - as created long time ago - I've sent improper HTTP status code from the 404 page (200 instead of 404), therefore NEON considered it proper output and processed, leaving it in somehow incorrect state.

So, right now it was apache issue, caused by stupid web developer - me in 2003... :)

Answer 4

I found that this is caused by not using the correct URL to check out the contents. I was using the url served by the web server when I typed the check out command eg "svn co http://blah.com/stuff_in_here/contents" I then played with the url until I found the real svn location that I could use in the command line eg "http://blah.com/svn/contents"

Answer 5

This was bothering me too. I solved it by removing my workspace and checking it out again.