TortoiseSVN 1.7.7 can't commit to Subversion 1.7.5 but TortoiseSVN 1.6 can?

1
votes

I was trying to set up a new Subversion repo on Ubuntu 12.04. Perhaps foolishly, I upgraded subversion to 1.7.5 using a PPA repository.

Now, I cannot perform a commit using TortoiseSVN 1.7.7

Error: Commit failed (details follow):
Error: Server sent unexpected return value (500 Internal Error) in response to POST
Error: request for '/usvn/svn/TestThis/!svn/me' <

I can apparently do a successful update using TortoiseSVN 1.7.7.
Also, using TortoiseSVN 1.6.x I can perform a successful commit. So, this maybe has something to do with the new HTTP protocol (redundant?) implemented in Subversion 1.7

The apache logs didn't shed much light for me. Except the failing client tries POST, whereas the older working client does a PUT. I assume that's an expected difference between the client versions?

192.168.0.25 - admin [21/Jun/2012:20:23:22 -0500] "POST /usvn/svn/TestThis/!svn/me HTTP/1.1" 500 538 "-" "SVN/1.7.5/TortoiseSVN-1.7.7.22907 neon/0.29.6"

192.168.0.20 - admin [21/Jun/2012:17:26:22 -0500] "PUT /usvn/svn/TestThis/!svn/wrk/d8430d5f-d87b-5141-8828-e810dab0904f/trunk/piechart/History.txt HTTP/1.1" 201 591 "-" "SVN/1.6.15 (r1038135)/TortoiseSVN-1.6.12.20536 neon/0.29.5"
2
svnapache2tortoisesvn
a 500 error also writes something to the apache error log. So you should check the error log as well, not just the access log. – Stefan
Not really, the error log was the first place that I looked. Even turning the loglevel all the way to debug yielded no extra info. See the comment below for the extra logging that I did need to enable. – user1473642

2 Answers

0
votes

So, it seems that the problem was that the path was being clobbered by some combination of an alias in the apache config and the DAV svn "Location" which is a bit like an alias. Mod_rewrite was messing up the path because the SVNParentPath was a subdirectory of the alias. It's a bit strange why the old Tortoise client worked anyways. The httpv2 protocol implemented in version 1.7 is claimed to have improved handling of redirects.

Anyhow, the normal apache logs were almost useless in figuring this out, they are not verbose in this regard, even if you turn the loglevel all the way to debug. Enabling the rewrite log was the key to diagnosis: (httpd.conf)

RewriteLogLevel 3

RewriteLog "/var/log/apache2/rewrite.log"

0
votes

Uncheck automatically adjust access right permissions...and check it back..this option is available under general tab of repository property