Justin Erenkrantz writes:
> On Wed, Nov 5, 2014 at 9:24 AM, Philip Martin
> wrote:
>> Configure a server with both mod_ssl (HTTPS) and mod_deflate (HTTP
>> compression). Start a checkout and the kill the server. The client
>> goes into an infinite loop in libsvn_ra_serf/update.c:handle_fetch
Philip Martin writes:
> handle_fetch (request=0x73e56038, response=0x73e918b8,
> handler_baton=0x73e611e0, pool=0x73e6d028)
> at ../src/subversion/libsvn_ra_serf/update.c:1152
> 1152if (SERF_BUCKET_READ_ERROR(status))
> (gdb) p status
> $13 = 0
So that's what hap
Philip Martin writes:
> Philip Martin writes:
>
>> handle_fetch (request=0x73e56038, response=0x73e918b8,
>> handler_baton=0x73e611e0, pool=0x73e6d028)
>> at ../src/subversion/libsvn_ra_serf/update.c:1152
>> 1152 if (SERF_BUCKET_READ_ERROR(status))
>> (gdb) p statu
Branko Čibej writes:
>> From the performance point of view there will be no big benefits to enable
>> log addressing for an existing repository, because the existing old part
>> of the repository will remain to be addressed physically.
>
> I disagree with your assessment. Certainly, as long as th
On 11.11.2014 20:40, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>>> From the performance point of view there will be no big benefits to enable
>>> log addressing for an existing repository, because the existing old part
>>> of the repository will remain to be addressed physically.
>> I disagree
... because it was apparently recently upgraded to libtool-2.4.3. Here's
the error from the log:
cd:
/home/buildslave27/slave27/svn-trunk-nightly/uploads/roll/prefix/bin/../share/libtool/config:
No such file or directory
This is because, in the latest version of libtool, config.guess is no
lon
6 matches
Mail list logo
