Thanks for looking into this.
On Thu, Feb 9, 2012 at 20:29, Nick Hengeveld <nickh_at_github.com> wrote:
> On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein <gstein_at_gmail.com> 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 have an
> configuration in my dev environment that handles requests with chunked
> transfer-encoding and we could feasibly deploy something like this to
> However, I'm now getting a different error on the client:
> svn: E235000: In file 'subversion/libsvn_ra_serf/update.c' line
> 1769: internal malfunction
> From what I can see at
> it looks like the client is trying to process an add/open file. The
> I'm testing is small and contains only one file, and this is what the server
> is returning for that file:
> <S:add-file name="README.txt" >
> <S:set-prop name="svn:entry:committed-rev">3</S:set-prop>
> <S:set-prop name="svn:entry:last-author">subversion.user</S:set-prop>
The S:txdelta element was not requested by the client, so it freaks
out when it sees the unknown element.
Control over whether the txdelta should be sent/not is within the
update-report that the client sends to the server. Take a look at the
"send-all" attribute on the S:update-report in the request. The
txdelta element should only be delivered to the client when
ra_neon wants the embedded txdelta within one giant response. ra_serf
only wants a barebones "what changed", and then it will issue multiple
GET calls to fetch the deltas individually. serf will pipeline these
GET requests over several connections.
Received on 2012-02-10 03:54:15 CET