8

Closed

Unable to sync project using Tortoise SVN

description

I am getting an XML Parsing failed error when I try to update the source from codeplex via SVN.

SVN support in codeplex has always been dismal but then the solution was to move the current copy to a different location and then pull a new set from the site, but this time, codeplex has reached a new height.

I have attached a screenshot of the error message I get

file attachments

Closed Aug 27, 2013 at 9:06 PM by pranavgk
This should be resolved now, let us know if you still face any issues.

comments

pranavgk wrote Jul 8, 2013 at 6:45 PM

Sorry for the delay in responding. Are you still having trouble with SVN?

suryapratap wrote Jul 9, 2013 at 5:53 AM

yes, I tried deleting the current repo and fresh checkout, still getting the same error "XML parsing failed: (400 Bad Request)"

pranavgk wrote Jul 9, 2013 at 10:46 PM

Are you using SVN 1.8? We have seen issues with 1.8 in the recent past, can you try 1.7.x instead?

suryapratap wrote Jul 10, 2013 at 5:27 AM

I tried with Tortoise SVN 1.7.13, now the the client just hangs with no error message. I have experienced this particular behavior earlier when trying to update a repo from codeplex but the resolution then was to just delete the local copy and check out once more. Currently the client hangs even when trying a fresh checkout.

I got a mail from someone at microsoft that says
I am sorry to hear that you are experiencing difficulties with SVN project support. We are doing some infrastructure improvements in the near future to make it operate more reliably in the future. In the meantime your best bet is to try again after a short while.
So I guess there is no choice but to wait for the "near future" whenever that is

pranavgk wrote Jul 10, 2013 at 6:22 PM

Yes we are, will keep you posted about that.

SZoppi wrote Jul 14, 2013 at 11:07 PM

I reported the error and got the same response from MS:
I am sorry to hear that you are experiencing difficulties with SVN project support. We are doing some infrastructure improvements in the near future to make it operate more reliably in the future. In the meantime your best bet is to try again after a short while.
Sorry again about the issues.
This is the error that's being show in the PNG another person attached:
XML parsing failed: (400 Bad Request)
On TortoiseSVN 1.8.0 if you turn http-compression OFF then you get the following:
Missing update-report close tag
This is clearly not an "infrastructure" issue. It's a protocol problem.

Although the following post indicates something like this problem (can't tell if it's the root cause or another one causing this error to be thrown) will be fixed in 1.8.1 and that it's related to having compression on, it's clear that turning compression off doesn't resolve the problem.

http://subversion.1072662.n5.nabble.com/Fix-for-svn-E175009-XML-parsing-failed-400-Bad-Request-td182428.html

This is (pretty much) rendering Codeplex unusable since I cannot revert to 1.7.x ...

I hope this is addressed soon.

PerrySharePoint wrote Jul 15, 2013 at 3:14 PM

This thread suggests that subversion 1.8.1 might come out soon, and help with this issue?

http://comments.gmane.org/gmane.comp.version-control.subversion.devel/143523

That would be good -- sspecially because I have been unable to find any info about codeplex doing anything about it.

SZoppi wrote Jul 15, 2013 at 3:44 PM

I'm uncertain that the issue identified to be resolved in 1.8.1 is going to address the CodePlex problem. It appears that the "bug" only occurred (in that string) when http-compression is "on" - but turning if off doesn't seem to clear the problem (as the bug notes suggested). Instead, it seems to surface another problem from CodePlex which happens when performing the update.

I am hopeful but surprised that it's being referred to as a CodePlex Infrastructure problem. Perhaps that's the same thing as "software" but the lack of input from the CodePlex team is a bit disappointing.

pranavgk wrote Jul 15, 2013 at 6:42 PM

While we have been facing infrastructural issues (to be resolved soon) with the SVN servers, I think you have a point too. We are investigating this aspect as well. Will let you know, as soon as we come across something significant.

jeroenp wrote Jul 25, 2013 at 12:28 PM

Indeed. SVN 1.8.1 only solves the first problem. The second problem is still there.

For now: stick to SVN 1.7.x if you still can.
http://wiert.me/2013/07/25/svnsubversion-and-codeplex-for-now-stick-to-svntortoisesvn-1-7-x-or-lower/

SZoppi wrote Jul 25, 2013 at 5:13 PM

It's still a problem and (unfortunately) I can't revert back to 1.7.x ...

To be clear, despite the title of this thread, the issue is not a TortoiseSVN problem. The problem occurs within the SVN interaction (1.8.x). (Verified at the SVN command line).

<vent>
I really don't understand why the Codeplex team is so silent on something like this. It has been nearly a month and there is no apparent progress. Unless there are just too few of us who use SVN on Windows (and I doubt that to be the case), this should have been addressed by now.
</vent>

jeroenp wrote Jul 25, 2013 at 7:41 PM

It might be an SVN issue too: I will check if the same happens with SVN on Google Code.
http://wiert.me/2013/07/25/svnsubversion-and-codeplex-for-now-stick-to-svntortoisesvn-1-7-x-or-lower/#comment-21486

I agree with your VENT. The SVN and CP people should sit together and let us know they did.

I send a tweet to both parties: no reaction yet.
To CodePlex: https://twitter.com/jpluimers/status/360366597715668992
To SVN: https://twitter.com/jpluimers/status/360361987089248259

jeroenp wrote Jul 25, 2013 at 7:56 PM

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.

SZoppi wrote Jul 25, 2013 at 8:45 PM

Thanks Jeroen ... I checked on Google, SourceForge, my own servers (all are 1.8.0 SVN) and two other repository sites - they all work just fine. It's DEFINITELY a Codeplex issue.

And now ... we wait ... still ...

jeroenp wrote Jul 31, 2013 at 8:49 PM

I tweeted to the CP team. Hopefully they'll react soon. https://twitter.com/jpluimers/status/362626009712959489

pranavgk wrote Jul 31, 2013 at 9:07 PM

Thank you all for your patience and sincere apologies for the inconvenience.

Here is an interim update:
We have got it working for SVN 1.8.1. The issue here was with the recent change in SVN, related to absolute vs relative paths. Please note, SVN 1.8.0 would still not work, because of the http-compression issue in SVN, as mentioned in the above comments.
While things should be working with SVN 1.8.1, the performance issues with the server are still being worked upon, so you could still face issues with larger repositories.

We are actively working on upgrading our servers and you should hear back from us soon.

jeroenp wrote Aug 2, 2013 at 4:46 PM

Thanks!
It works for SVN 1.8.1: https://gist.github.com/jpluimers/6140864

Summary:

C:\dev\BeSharp.CodePlex.com>svn --version
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 19:58:17 on x86-microsoft-windows
...
C:\dev\BeSharp.CodePlex.com>svn checkout https://besharp.svn.codeplex.com/svn .
A BuildProcessTemplates
...
A Version-control-URLs.txt
Checked out revision 102143.

C:\dev\BeSharp.CodePlex.com>svn info
Path: .
Working Copy Root Path: C:\dev\BeSharp.CodePlex.com
URL: https://besharp.svn.codeplex.com/svn
Relative URL: ^/
Repository Root: https://besharp.svn.codeplex.com/svn
...

C:\dev\BeSharp.CodePlex.com>svn update
Updating '.':
At revision 102143.

jeroenp wrote Aug 2, 2013 at 5:32 PM

But commit fails:

C:\dev\BeSharp.CodePlex.com\Scripts>svn commit --username snd\jeroenp_cp --password ... --editor-cmd notepad.exe
Adding List-Installed-Programs-through-Registry-Uninstall-keys.ps1
svn: E175002: Commit failed (details follow):
svn: E175002: HEAD request on '/svn/Scripts/List-Installed-Programs-through-Registry-Uninstall-keys.ps1' failed: 405 Met
hod Not Allowed
svn: E175002: Your commit message was left in a temporary file:
svn: E175002: 'C:\dev\BeSharp.CodePlex.com\svn-commit.tmp'

C:\dev\BeSharp.CodePlex.com\Scripts>svn --version
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 19:58:17 on x86-microsoft-windows
...

jeroenp wrote Aug 2, 2013 at 5:35 PM

The bad thing: SVN 1.7.5 now fails too.

https://gist.github.com/jpluimers/6141011

svn, version 1.7.5 (r1336830) fails with svn: E130003: XML data was not well-formed

7zip of my local checkout (before doing the svn update) is attached.

Decompress recursive, inside the directory perform a svn update, then watch it fail.

suryapratap wrote Aug 12, 2013 at 1:23 PM

on the checkout side, I find that using the repo browser and checking out small portions now work.
It is a pain but then it is about the only thing that I found usable now

jeroenp wrote Aug 13, 2013 at 3:19 PM

This takes too long. I'm moving to BitBucket HG.

pranavgk wrote Aug 14, 2013 at 6:56 PM

@jeroenp: Please hold on, the servers should be up real soon (early next week), only certificate and IP configuration is pending.

pranavgk wrote Aug 26, 2013 at 9:16 PM

All, this should be resolved now. Please let us know if you still face any issues.

suryapratap wrote Aug 28, 2013 at 5:54 PM

Seems like the issue is resolved, I could sync with the sharpmap repo

pranavgk wrote Aug 28, 2013 at 6:35 PM

@SuryaPratap: Thanks for the confirmation.

RaymondEllis wrote Sep 1, 2013 at 7:22 AM

Just want to point out, that you may have to checkout to a new folder.