The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,706 other followers

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:

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:

  1. 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.
  2. Disable http-compression (see below)

I tried both, and they will get you a new error.

Solution 2: disable http-compression.

  1. Make a backup of the file %APPDATA%\Subversion\servers
  2. In a text editor, open the file %APPDATA%\Subversion\servers
  3. Under [groups] add this line:
    codeplex = *.svn.codeplex.com
  4. Add this section:
    [codeplex]
    http-compression = no
  5. Save the file
  6. Retry your SVN / TortoiseSVN operation

–jeroen

17 Responses to “SVN/Subversion and CodePlex: for now stick to SVN/TortoiseSVN 1.7.x or lower”

  1. 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

  2. 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.

      • 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.

          1. Make a backup of the file %APPDATA%\Subversion\servers
          2. In a text editor, open the file %APPDATA%\Subversion\servers
          3. Under [groups] add this line:
            codeplex = *.svn.codeplex.com
          4. Add this section:
            [codeplex]
            http-compression = no
          5. Save the file
          6. Retry your SVN / TortoiseSVN operation
      • 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: