SVN/Subversion and CodePlex: for now stick to SVN/TortoiseSVN 1.7.x or lower
Posted by jpluimers on 2013/07/25
Introduction
Over the last month or so, two incompatibilities between SVN and CodePlex have risen. I’m not sure which side caused it (see below for the error messages), who will fix it and when. Some details I bumped into.
CodePlex knows about both issue. I’m not sure the SVN team does yet about the second issue.
Recommendation
If you are using CodePlex with SVN/SubVersion, then you shoud stick to SVN versions lower than 1.8, or you will run into the error messages below.
So:
- Stick to version 1.7.x or lower of SVN and/or TortoiseSVN.
- DO NOT UPGRADE YOUR LOCAL CHECKOUT TO 1.8 OR HGHER!
(you cannot downgrade your local checkout to a lower version)
You can find older 1.7.x versions of SVN here:
- Tortoise older downloads (at the time of writing: 1.7.13 is the youngest)
- SVN older downloads (at the time of writing: 1.7.11 is the youngest)
Issues with CodePlex and SVN 1.8.x
Error: XML parsing failed: (400 Bad Request)
When using TortoiseSVN 1.8.0, I got this error:
Command: Checkout from https://besharp.svn.codeplex.com/svn, revision HEAD, Fully recursive, Externals included
Updating: C:\Development\Besharp.CodePlex.com
Error: XML parsing failed: (400 Bad Request)
Completed!:
The same happens on the command-line:
C:\Development>svn checkout https://besharp.svn.codeplex.com/svn Besharp.CodePlex.com
svn: E175009: XML parsing failed: (400 Bad Request)
Error: Missing update-report close tag
This happens using SVN 1.8.0 (with http-compression disabled) or SVN 1.8.1.
TortoiseSVN error:
Command: Checkout from https://besharp.svn.codeplex.com/svn, revision HEAD, Fully recursive, Externals included
Updating: C:\Development\Besharp.CodePlex.com
Error: Missing update-report close tag
Completed!:
SVN error:
C:\Development>svn checkout https://besharp.svn.codeplex.com/svn Besharp.CodePlex.com
svn: E175009: Missing update-report close tag
Bummer.
Solutions I tried
The XML parsing failed: (400 Bad Request) error is caused by a compression header not correctly being handled in certain circumstanced (not limited to CodePlex).
This is explained at Re: Fix for svn: E175009: XML parsing failed: (400 Bad Request).
There are two possible solutions:
- Upgrade to SVN 1.8.1 or higher (release last week):
– SVN 1.8.1
– TortoiseSVN 1.8.1
TortoiseSVN version 1.8.1.24570 got released this week which includes the updated SVN command line tools.
win32svn has not yet been updated. - Disable http-compression (see below)
I tried both, and they will get you a new error.
Solution 2: disable http-compression.
- Make a backup of the file %APPDATA%\Subversion\servers
- In a text editor, open the file %APPDATA%\Subversion\servers
- Under [groups] add this line:
codeplex = *.svn.codeplex.com - Add this section:
[codeplex]
http-compression = no
- Save the file
- Retry your SVN / TortoiseSVN operation
–jeroen
The Wiert Corner - irregular stream of stuff 
Arnaud Stevenaert said
Hi guys,
I had the same problem which I have been able to fix by installing the following version of TortoiseSVN:
TortoiseSVN 1.8.2, Build 24708 – 64 Bit , 2013/08/27 19:20:39
Enjoy !
Kind Regards,
Arnaud
jpluimers said
In the mean time, CodePlex also updated their servers which might have helped too.
Since it took so long, I’ve moved away to Mercurial on BitBucket and found out that DVCS gives me way more flexibility and ease of mind (as I have the full repository local in case something bad happens).
I also found out the Mercurial tools (command-line, TortoiseHG and SourceTree) are really nice to use.
–jeroen
IL said
Same for Google Code, svn checkout just timeouts after a long waiting.
jpluimers said
You have a Google Code repository I can test this with?
jpluimers said
SVN 1.8.1. with GoogleCode works fine on this repository:
C:\Development>svn checkout http://delphi-code-coverage.googlecode.com/svn Delphi-Code-Coverage.GoogleCode.com
….
Checked out revision 175.
IL said
I haven’t looked at SVN 1.8.1 release. Timeout happened with 1.8.0.
svn co http://firemonkey-container.googlecode.com/svn/trunk/ firemonkey-container
svn co http://transparent-canvas.googlecode.com/svn/trunk/ transparent-canvas
jpluimers said
OK. Both work fine with SVN 1.8.1.
Did you try to disable the http-compression in SVN 1.8.0?
IL said
I believe http-compression is server side http option. At least “svn –help co” doesn’t show such option.
I see in SVN 1.8.1 google code is OK, as you said.
jpluimers said
The “http-compression” workaround for SVN 1.8.0 is client side.
Just try it and see if that works.
IL said
Please advise exact SVN command to try.
IL said
I just receive this on Windows after a very-long-to-much-to-be-counted time:
>svn checkout http://transparent-canvas.googlecode.com/svn/trunk/ transparent-canvas
svn: E175002: Unable to connect to a repository at URL ‘http://transparent-canvas.googlecode.com/svn/trunk’
svn: E175002: OPTIONS request on ‘/svn/trunk’ failed: 408 Request Time-out
By disabling client http-compression setting do you mean this http://www.visualsvn.com/support/svnbook/advanced/confarea/#svn.advanced.confarea.windows-registry.ex-1 ?
jpluimers said
It is much easier: no registry, just a configuration file. Follow the steps from my post:
Solution 2: disable http-compression.
codeplex = *.svn.codeplex.com[codeplex]
http-compression = no
IL said
I’ve tried both registration entry from visualsvn and config file from here http://www.apache.org/dev/version-control.html
registry file:
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\global]
“#http-compression”=”no”
config file %USERHOME%\.subversion\servers:
[global]
http-compression = no
IL said
Bummer! I have upgraded TortoiseSVN to 1.8.1, but neither it, nor disabling http-compression helped. Thank you for step-by-step instructions.
I’m lost now, cause I don’t see any reason why the timeout happens. It happens on GoogleCode, on SourceForge I can check out just fine.
I can do any operation with locally installed VisualSVN Server 2.6.2. I’ve uninstalled antivirus that could possibly alter HTTP responses.
I guess I know, what is it – IPv6! Our firewall just blocks it, and my computer runs Windows 7, and there is IPv6 over IPv4 preference in nslookup response
>nslookup asmprofiler.googlecode.com
Non-authoritative answer:
Name: googlecode.l.googleusercontent.com
Addresses: 2a00:1450:4010:c04::52
74.125.143.82
Aliases: asmprofiler.googlecode.com
Is any way to tell SVN use IPv4 instead of IPv6?
IL said
Disabling http-compression didn’t work out, I’m in the dark. Perhaps, capturing network trace might shed some light.
IL said
Just for the record, I have to put down protocol inspector of a firewall to make svn checkout happen. Things were worse, not only on google code, I couldn’t check out tdbf from its official repository on sf.net before figuring out what to do. So the timeout issue seems not related to IPv6 as I supposed before (sf.net is IPv4 only yet), but is closely related to many cases in SVN mail-list and throughout the web on 1.8 and proxy/firewall compatibility. In short, it is proxy serving HTTP 1.1 protocol doesn’t fully implement features of the protocol. I’ve noticed, that SVN 1.8 client just hangs on HTTP Options command, keeping connection open until timeout. This incompatibility hopefully will be resolved in next SVN version obviously through fallback to HTTP 1.0. Perhaps using HTTPS is a workaround, save for I didn’t tested.
jpluimers said
Has this been reported to the SVN people?