[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of ra_serf?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 3 May 2012 14:19:43 +0200

On Thu, May 3, 2012 at 3:13 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Wed, May 2, 2012 at 8:11 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> On Wed, May 2, 2012 at 6:45 PM, Greg Stein <gstein_at_gmail.com> wrote:
>>...
>>> There is a single open issue that I believe warrants a fix for 1.8, and that
>>> is the HTTP/1.0 proxy work. That has been tested with a pre-release build of
>>> serf 1.1 for a new API. Before releasing that, I'm waiting on some feedback
>>> from Apache OpenOffice, which won't arrive until after they get past the
>>> insanity of their release this week. So when 1.1 is released, then I'll
>>> enable the code to fix the proxy issue (it's in there, just not
>>> fully-enabled).
>>
>> There is the list of issues on roadmap.html (currently 7 issues). But
>> a bit more accurate is simply querying the bug database for
>> component==libsvn_ra_serf. That currently shows 17 issues. Definitely
>> not all blockers, but certainly more than one (anything that really
>> breaks some normal operations, basically).
>
> Yeah... I ran that query after responding. Hadn't seen most of those
> other issues. I'll sort 'em out.

Thanks.

>>
>>>> (not to
>>>> mention unkown problems because ra_serf hasn't had enough coverage and
>>>> problems aren't always adequately reported).
>>>
>>> All software has unknown problems. I don't believe there are any more in
>>> ra_serf than any other code. If you believe otherwise, then start filing
>>> issues.
>>
>> Sure, sure, we can't fix what we don't know, I get that.
>
> Please understand my frustration. I've wanted to see ra_serf as the
> default for years, but nobody steps up to test it. Then we get near
> the release and all those people say "not tested", and we kick the can
> down the road. Yet Again.
>
> We have to stop kicking it and ship it instead. We ship all kinds of
> drastic changes (wc-ng, anybody?). This doesn't even get close to
> "drastic", yet there is some irrational fear, and bang... can down the
> road again.

Yeah, I understand. It's a problem, and I certainly understand your
frustration with this situation.

That's why I posted this: I'm getting the feeling we're going down the
same road again as last year, silently, without anybody saying so. So
I thought I'd mention the elephant in the room (at the risk of getting
some cans thrown at me ;-)). Preferably before we're in Berlin,
discussing what's blocking the release like last year again ...

Compared to wc-ng: in that case there was no choice, everyone had to
go forward. There really was no other way. In this case there's always
this working alternative, which is also supported very well and mature
with its broad svn deployment etc etc...

It's tempting to just say "oh, I had this problem with serf ... but no
time to investigate now ... well maybe it's not mature enough yet ...
I'll switch to neon for the time being ... maybe switch back somewhat
later, after someone else worked out the wrinkles (and maybe I'll
report the issue, you know, when I have some more time) ..." But if
everyone (or most) starts to think that way, those wrinkles might
never get ironed out ... Maybe we should just disable ra_neon on trunk
(for developer builds), so we're a bit more forced to use serf.

Also, it's not enough to use serf on smallish working copies (like I
do @home, when I'm working with svn.a.o/subversion). And it should
also be used in corporate/LAN/firewalled/antivirus-controlled
environments. That's not always easy to do. But I'll try to contribute
a bit more by using more serf @work :-).

OTOH: there might be this one blocking issue (like the one I reported
in this thread ... see below), making serf a no-go as a default in my
corporate environment. So it's hard for me to test it further. I just
can't reliably work with it right now.

>...
> For *you* and your day-to-day work, it should have been the default
> for over two years now.

You're right, but I must admit ... it hasn't (maybe I used it for a
short while way back, but gave up after too many problems ... and see
above about the temptations). So sorry, I'll try to do better. Better
late than never I suppose ...

>...
>>...
>> Sorry, I was handwaving a bit here. It's not really crashing currently
>> (I previously had crashes with serf, but that was with one of the 1.7
>> betas I believe, could be the issue you mention was fixed in 1.7). But
>> now it's erroring out with "svn: E730053: Error retrieving REPORT
>> (730053): An established connection was aborted by the software in
>> your host machine." That's with a 1.7.4 client on Windows and a 1.7.3
>> server also on Windows.
>>
>> I'll file a proper issue for this (but not today, it's already past 2 am).
>
> No problem. That is either a server-side problem, or the client
> stopped reading the network and the server timed out the request. It
> would be useful to look at the server logs for that.

Ok, I filed an issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=4174 (serf:
checkout / export errors out with "svn: E730053: Error retrieving
REPORT (730053)").

Marked it blocking for 1.8.

If there's anything I can do to further investigate ... let me know
(but I'm a bit limited in what I can do here @work).

-- 
Johan
Received on 2012-05-03 14:20:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.