Hello,
I was checking out a Git repository (
https://github.com/NuGet/PoliteCaptcha.git) when I encountered the
following error near the end of getting all the files:
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much informat
On 02/07/2012 02:49 PM, TheBlueSky .Net wrote:
> Hello,
>
> I was checking out a Git repository
> (https://github.com/NuGet/PoliteCaptcha.git) when I encountered the
> following error near the end of getting all the files:
>
> Subversion encountered a serious problem.
> Please take the time to re
C. Michael Pilato collab.net> writes:
>
> Well, supported by whom?
>
> At first blush, it would appear that the GitHub server didn't transmit a
> valid svn:entry:committed-rev property value for one of the directories your
> checkout is attempting to register with Subversion's working copy
> a
I'm happy to try it with 1.7, too, but couldn't easily figure out the
correct checkout URL:
$ svn co https://github.com/NuGet/PoliteCaptcha.git
svn: E175009: Unable to connect to a repository at URL
'https://github.com/NuGet/PoliteCaptcha.git'
svn: E175009: XML parsing failed: (411 Length Required
The GitHub server is definitely trying to transmit the svn:entry: property
set ("svn:entry:committed-rev", "svn:entry:committed-date",
"svn:entry:last-author"), as can be seen in your output below. But there
are some places where it fails to do so.
For example, the directory
"/home/cmpilato/tests
On Wed, Feb 8, 2012 at 14:47, C. Michael Pilato wrote:
> I'm happy to try it with 1.7, too, but couldn't easily figure out the
> correct checkout URL:
>
> $ svn co https://github.com/NuGet/PoliteCaptcha.git
> svn: E175009: Unable to connect to a repository at URL
> 'https://github.com/NuGet/Polite
On Wed, Feb 8, 2012 at 15:51, Greg Stein wrote:
>...
> This looks like the problem where ra_serf starts out with an HTTP/1.1
> request: specifically, a chunked request. This is typically caused by
> a non-1.1 proxy in front of the server, such as nginx.
>
> Ideally, github would switch to a newer/
Thanks for checking - we want to be fully compatible so any information
like this helps.
The checkout URL is the same as the HTTP clone URL, and the .git suffix is
optional for both git and svn clients.
I may have misunderstood what's up with the ra_serf library, I thought that
was related to HTT
Nick Hengeveld wrote on Wed, Feb 08, 2012 at 12:34:52 -0800:
> Thanks for checking - we want to be fully compatible so any information
> like this helps.
>
> The checkout URL is the same as the HTTP clone URL, and the .git suffix is
> optional for both git and svn clients.
>
> I may have misunder
That pointed me in the right direction, thanks.
It was a bug related to tag versions, and we just deployed a fix. I was
able to do a checkout with a 1.7 client, let me know if you have any
problems.
On Wed, Feb 8, 2012 at 12:41 PM, C. Michael Pilato wrote:
> The GitHub server is definitely tryi
I think the document that I'd read previously was this:
http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/http-protocol-v2.txt
In particular, this section:
ra_serf will send an OPTIONS request when creating a new
ra_session. mod_dav_svn will send back what it already sen
Nick Hengeveld writes:
> We're not returning the new custom headers, so I'd expected that ra_serf
> would fall back.
As Greg explained serf doesn't get this far, probably because the
request with "Transfer-encoding: chunked" is rejected by the server.
Using neon, which also has v2 support, does
Nick Hengeveld writes:
> It was a bug related to tag versions, and we just deployed a fix. I was
> able to do a checkout with a 1.7 client, let me know if you have any
> problems.
Oooh! Nasty client crash:
Awc/tags/v0.3/3rdParty/xunit/xunit.extensions.xml
Awc/tags/v0.3/3rdParty/xunit
[Philip Martin]
> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
> @@ -410,7 +410,7 @@
>/* Resize the stringbuf to make room for the (approximate) size of
> output, to avoid repeated resizes later.
>
Peter Samuelson writes:
> [Philip Martin]
>> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
>> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
>> @@ -410,7 +410,7 @@
>>/* Resize the stringbuf to make room for the (approximate) size of
>> output, to avo
Sorry if I have posted this in the not-right place :)
It's not like someone is going to die if I didn't checked out a git repo
from SVN client; I was only testing it as other people have done it
successfully.
Anyway, the only reason I posted in this mailing list is because the error
message told
[TheBlueSky .Net]
> Sorry if I have posted this in the not-right place :)
That's fine. It was an assertion failure which, by definition, is a
bug in the Subversion client. The bug was triggered by a bug on the
Github server side, but it's still a bug in the client.
Also, happily, someone at Gi
On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
So... this isn't really so much about "svn must allow for HTTP/1.0"
> (yes, we'll work on it), but that github could also provide better
> service overall by updating its proxy.
>
I've been looking into what it would take to update our proxy. I
Nick Hengeveld wrote on Thu, Feb 09, 2012 at 17:29:14 -0800:
> On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
>
> So... this isn't really so much about "svn must allow for HTTP/1.0"
> > (yes, we'll work on it), but that github could also provide better
> > service overall by updating its prox
Hey Nick!
Thanks for looking into this.
On Thu, Feb 9, 2012 at 20:29, Nick Hengeveld wrote:
> On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
>
>> So... this isn't really so much about "svn must allow for HTTP/1.0"
>> (yes, we'll work on it), but that github could also provide better
>> serv
On Thu, Feb 9, 2012 at 21:53, Daniel Shahaf wrote:
> Nick Hengeveld wrote on Thu, Feb 09, 2012 at 17:29:14 -0800:
>...
>> What's the best way to track down issues like this? I'm not currently
>> familiar
>> with svn client debugging but would be happy to learn.
>>
>
> For svn client debugging, th
On 09.02.2012 19:08, Philip Martin wrote:
Peter Samuelson writes:
[Philip Martin]
--- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
+++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
@@ -410,7 +410,7 @@
/* Resize the stringbuf to make room for the (approximate
On Thu, Feb 9, 2012 at 6:53 PM, Greg Stein wrote:
The S:txdelta element was not requested by the client, so it freaks
> out when it sees the unknown element.
>
Makes sense, we just deployed an update that fixes that and a few other
bits that turned up while testing with ra_serf.
The chunked req
On Feb 14, 2012 12:01 AM, "Nick Hengeveld" wrote:
>
> On Thu, Feb 9, 2012 at 6:53 PM, Greg Stein wrote:
>
>> The S:txdelta element was not requested by the client, so it freaks
>> out when it sees the unknown element.
>
>
> Makes sense, we just deployed an update that fixes that and a few other
b
Stefan Fuhrmann wrote:
> [...] As already discussed on IRC, the real cause here
> is that _ensure() should follow the first invariant listed
> in svn_string.h by allocating *additional* space for
> the terminating 0. In particular svn_stringbuf_ensure()
> is inconsistent with svn_stringbuf_create_
25 matches
Mail list logo
