RE: [DISCUSS] delete ra_neon

Even with a sensible timeout of 20/30 seconds instead of half an hour, that
value would still be much too high for blocking a GUI tool. The cancel
problem must also be fixed.

You press 'Cancel' in the TortoiseSVN dialog.. And have to wait for 30
minutes until it is processed.

On *nix you don't have this problem for handling ^C, as that breaks IO, but
in GUIs that doesn't work.

                Bert

From: lieven.govaerts_at_gmail.com [mailto:lieven.govaerts_at_gmail.com] On Behalf
Of Lieven Govaerts
Sent: maandag 21 mei 2012 19:28
To: Johan Corveleyn; dev_at_subversion.apache.org
Cc: Greg Stein
Subject: Re: [DISCUSS] delete ra_neon

On Mon, May 21, 2012 at 1:47 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:

On Sat, May 19, 2012 at 9:58 PM, Greg Stein <gstein_at_gmail.com> wrote:
> So far, beyond Philip's concern about traffic/CPU tradeoff, and a
> couple open issues... I think we're in good shape to pull the lever.

As I said elsethread, this is probably the best overview of open
ra_serf blockers:

http://subversion.tigris.org/issues/buglist.cgi?subcomponent=libsvn_ra_serf
<http://subversion.tigris.org/issues/buglist.cgi?subcomponent=libsvn_ra_serf
&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_mileston
e=1.8.0>
&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_mileston
e=1.8.0

For convenience, I'm pasting the current result of this query here:

3968: DEFAULT_HTTP_TIMEOUT is way too high for serf
3969: ra_serf should check for cancellation from loops around
serf_context_run()

I think these two issues are overlapping, at least in their root cause and
solution. Added a suggestion to issue 3968 on how to fix them.

Lieven

 
Received on 2012-05-21 19:34:28 CEST