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
>
>
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
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
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,
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
TTP/1.1 header) and RFC 7232
> recommends to prefer using ETag instead of Last-Modified [2].
>
> Given all above I propose to stop adding Last-Modified header for HTTP
> GET responses.
Your analysis looks sound, but I wonder if doing this would have any
serious effect on checkout/u
adding Last-Modified header for HTTP
GET responses.
[1] https://tools.ietf.org/html/rfc7232#section-2.2.1
[2] https://tools.ietf.org/html/rfc7232#section-3.3
--
Ivan Zhakov
Index: subversion/mod_dav_svn/repos.c
===
--- subversion
22 matches
Mail list logo