Daniel:
On Mon, Nov 25, 2019 at 1:31 PM Daniel Shahaf
wrote:
> Doug Robinson wrote on Mon, 25 Nov 2019 14:11 +00:00:
> > Can we get this fix back-ported into 1.10.x please? Breaking an LTS is
> > unfortunate as is waiting until the next LTS.
>
> r1866425 is already in
>
> https://svn.apache.org/
Doug Robinson wrote on Mon, 25 Nov 2019 14:11 +00:00:
> Can we get this fix back-ported into 1.10.x please? Breaking an LTS is
> unfortunate as is waiting until the next LTS.
r1866425 is already in
https://svn.apache.org/repos/asf/subversion/branches/1.10.x/STATUS?p=r1870409.
It will likely recei
Folks:
Can we get this fix back-ported into 1.10.x please? Breaking an LTS is
unfortunate as is waiting until the next LTS.
Cheers.
Doug
On Wed, Sep 4, 2019 at 8:03 PM Johan Corveleyn wrote:
> On Wed, Sep 4, 2019 at 2:47 PM Johan Corveleyn wrote:
> >
> > On Wed, Sep 4, 2019 at 2:01 PM Brank
On Wed, Sep 4, 2019 at 2:47 PM Johan Corveleyn wrote:
>
> On Wed, Sep 4, 2019 at 2:01 PM Branko Čibej wrote:
> >
> > On 04.09.2019 11:44, Johan Corveleyn wrote:
> > > On Tue, Sep 3, 2019 at 8:01 AM Branko Čibej wrote:
> > [...]
> > >>> Anyway, how about bringing this feature back in some form?
>
On Wed, Sep 4, 2019 at 2:01 PM Branko Čibej wrote:
>
> On 04.09.2019 11:44, Johan Corveleyn wrote:
> > On Tue, Sep 3, 2019 at 8:01 AM Branko Čibej wrote:
> [...]
> >>> Anyway, how about bringing this feature back in some form?
> >>> - Revert r1724790?
> >> This is clearly the simplest solution, b
On 04.09.2019 11:44, Johan Corveleyn wrote:
> On Tue, Sep 3, 2019 at 8:01 AM Branko Čibej wrote:
[...]
>>> Anyway, how about bringing this feature back in some form?
>>> - Revert r1724790?
>> This is clearly the simplest solution, but I have no idea what the
>> performance impact would be. From lo
On Tue, Sep 3, 2019 at 8:01 AM Branko Čibej wrote:
>
> On 02.09.2019 16:20, Johan Corveleyn wrote:
> > On Fri, Jan 15, 2016 at 1:58 PM Ivan Zhakov wrote:
> >> On 7 January 2016 at 10:34, Ivan Zhakov wrote:
> >>> On 6 January 2016 at 08:14, Greg Stein wrote:
> Personally, I'd be more intere
On 02.09.2019 16:20, Johan Corveleyn wrote:
> On Fri, Jan 15, 2016 at 1:58 PM Ivan Zhakov wrote:
>> On 7 January 2016 at 10:34, Ivan Zhakov wrote:
>>> On 6 January 2016 at 08:14, Greg Stein wrote:
Personally, I'd be more interested in the effects on the network and its
caching ability.
On Fri, Jan 15, 2016 at 1:58 PM Ivan Zhakov wrote:
> On 7 January 2016 at 10:34, Ivan Zhakov wrote:
> > On 6 January 2016 at 08:14, Greg Stein wrote:
> >> Personally, I'd be more interested in the effects on the network and its
> >> caching ability. Do we really need to save CPU/IO on the server
On 7 January 2016 at 10:34, Ivan Zhakov wrote:
> On 6 January 2016 at 08:14, Greg Stein wrote:
>> Personally, I'd be more interested in the effects on the network and its
>> caching ability. Do we really need to save CPU/IO on the server? Today's
>> servers seem more than capable, and are there r
On 04.01.2016 17:20, Philip Martin wrote:
Stefan Fuhrmann writes:
On 04.01.2016 14:25, Philip Martin wrote:
- The number of system calls made by Apache goes down
68822 to 50664 for hot FSFS cache
Do you have quick way to find out which files
we are reading in that case? My gue
On 6 January 2016 at 08:14, Greg Stein wrote:
> Personally, I'd be more interested in the effects on the network and its
> caching ability. Do we really need to save CPU/IO on the server? Today's
> servers seem more than capable, and are there really svn servers out in the
> wild getting so crushe
Ivan Zhakov writes:
> On 4 January 2016 at 16:25, Philip Martin wrote:
>>
>> When I checkout Subversion trunk from my local mirror I cannot measure a
>> client gain, but I can measure better server efficiency:
>>
>> - The CPU used by Apache goes down from 1.2s to 1.1s.
>>
>> - The number of sy
Personally, I'd be more interested in the effects on the network and its
caching ability. Do we really need to save CPU/IO on the server? Today's
servers seem more than capable, and are there really svn servers out in the
wild getting so crushed, that this is important? It seems that as long as
pro
On 4 January 2016 at 16:25, Philip Martin wrote:
> Branko Čibej writes:
>
>> Your analysis looks sound, but I wonder if doing this would have any
>> serious effect on checkout/update times; after all, the bulk of the work
>> there is in report generation, only HTTPv2 is affected by GET response
>
Stefan Fuhrmann writes:
> On 04.01.2016 14:25, Philip Martin wrote:
>> - The number of system calls made by Apache goes down
>>
>>68822 to 50664 for hot FSFS cache
>
> Do you have quick way to find out which files
> we are reading in that case? My guess would
> be a fair bit of revpro
On 04.01.2016 14:25, Philip Martin wrote:
Branko Čibej writes:
Your analysis looks sound, but I wonder if doing this would have any
serious effect on checkout/update times; after all, the bulk of the work
there is in report generation, only HTTPv2 is affected by GET response
construction.
Wh
Philip Martin writes:
> $ svn pg --revprop -r2 svn:date wc
> 2017-01-04T12:52:02.154787Z
>
> I see a Last-Modified varying with the current time:
>
> Last-Modified: Mon, 04 Jan 2016 12:57:06 GMT\r
>
> Last-Modified: Mon, 04 Jan 2016 12:57:53 GMT\r
The patch may change the caching behaviour for s
Branko Čibej writes:
> Your analysis looks sound, but I wonder if doing this would have any
> serious effect on checkout/update times; after all, the bulk of the work
> there is in report generation, only HTTPv2 is affected by GET response
> construction.
When I checkout Subversion trunk from my
Branko Čibej writes:
> The only really valid reason for removing that code is your point that
> we can't guarantee compliance of the Last-Modified header value compared
> with the Date header value. There's another solution for that ... we
> could check those values in mod_dav_svn and adjust Last
On 30.12.2015 15:50, Ivan Zhakov wrote:
> Currently mod_dav_svn sets ETag and Last-Modified HTTP headers for GET
> responses. These headers are optional and and are not used by
> Subversion client. But they used by browsers and intermediate proxies
> to cache responses.
>
> ETag header is cheap to
21 matches
Mail list logo
