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

Re: svn commit: r1411671 - /subversion/trunk/subversion/libsvn_ra_serf/serf.c

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 20 Nov 2012 11:34:27 -0500

On 11/20/2012 10:19 AM, Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>>> Author: cmpilato
>>> URL: http://svn.apache.org/viewvc?rev=1411671&view=rev
>>> Log:
>>> Minor logic simplification.
>>> * subversion/libsvn_ra_serf/serf.c
>>> (load_config): Simplify timeout calculations, since we know
>>> DEFAULT_HTTP_TIMEOUT is non-negative and we know the
>>> get-time-from-config path errors out on negative values.
>> Oops -- that logic was there to catch the fact that the default 3600 seconds goes negative in the 32-bit variable it's assigned to.
>> It's stupid and backwards for at least two reasons.
>> 1) Bert says on IRC, "The timeout value in neon was used for a
>> completely different purpose: In neon: complete request timeout, in
>> serf: chunk received timeout. Default http timeout is 30 or 60
>> minutes. A bit long for waiting for a tcp segment."
> This value is also affected by the http-timeout setting in
> .subversion/servers which means users may have customised it. If it
> means something different for serf should we introduce a new constant
> and new config setting?

I don't think there's a meaningful (to users) difference between Neon's and
Serf's usage of the http-timeout configuration setting. Both are meant to
limit the amount of time the client spends waiting on something networkish
to happen, right?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-11-20 17:35:07 CET

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.