On 29.01.2016 15:37, Evgeny Kotkov wrote:
Daniel Shahaf writes:
Well, it isn't consensus, but there's an old fallback we can use:
pick an agreed-upon third party and let him decide.
So let's ask a mod_dav/mod_dav_svn dev for his opinion and do what he says.
It seems like we still don't have
Evgeny Kotkov wrote on Fri, Jan 29, 2016 at 17:37:28 +0300:
> Daniel Shahaf writes:
>
> > Well, it isn't consensus, but there's an old fallback we can use:
> > pick an agreed-upon third party and let him decide.
> >
> > So let's ask a mod_dav/mod_dav_svn dev for his opinion and do what he says.
>
Daniel Shahaf writes:
> Well, it isn't consensus, but there's an old fallback we can use:
> pick an agreed-upon third party and let him decide.
>
> So let's ask a mod_dav/mod_dav_svn dev for his opinion and do what he says.
It seems like we still don't have a consensus here. I still say we shou
On 15 January 2016 at 09:26, Daniel Shahaf wrote:
> Evgeny Kotkov wrote on Thu, Jan 14, 2016 at 18:40:11 +0300:
>> Not quite sure on how do we continue from here.
>
> Well, it isn't consensus, but there's an old fallback we can use:
> pick an agreed-upon third party and let him decide.
>
> So let'
On 13.01.2016 15:33, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
If I replace apr_palloc() with malloc() / free() and patch mod_dav to avoid
creating the propdb->p subpools, I still see inadequate memory consumption.
The environment is close to the one reported by the user, and preparing a
4.5
Evgeny Kotkov wrote on Thu, Jan 14, 2016 at 18:40:11 +0300:
> Not quite sure on how do we continue from here.
Well, it isn't consensus, but there's an old fallback we can use:
pick an agreed-upon third party and let him decide.
So let's ask a mod_dav/mod_dav_svn dev for his opinion and do what he
Daniel Shahaf writes:
>> I believe that (1) is much harder than (2).
>>
>> The rewrite of mod_dav pool's usage is a recipe for rarely reproducible
>> crashes caused by lifetime issues. The functions and callbacks often modify
>> or attach allocated data to other objects. We'd also need to deal
Evgeny Kotkov wrote on Wed, Jan 13, 2016 at 17:33:36 +0300:
> Daniel Shahaf writes:
>
> > I still do not see the problem. mod_dav is not a huge amount of code,
> > and the work you describe does not sound too hard. Why didn't your
> > attempt to patch mod_dav succeed?
>
> [...]
>
> > Option (
Daniel Shahaf writes:
> I still do not see the problem. mod_dav is not a huge amount of code,
> and the work you describe does not sound too hard. Why didn't your
> attempt to patch mod_dav succeed?
[...]
> Option (1) does not have "unknown complexity". According to what you
> wrote above, i
On 30.12.2015 16:49, Evgeny Kotkov wrote:
Evgeny Kotkov writes:
Stefan Fuhrmann writes:
Thanks, it would be nice if could do something within Subversion because
httpd and apr patches may take a while to trickle down into releases.
Meanwhile, I posted a patch for mod_dav on the httpd dev lis
Evgeny Kotkov wrote on Tue, Jan 05, 2016 at 19:08:41 +0300:
> Daniel Shahaf writes:
>
> >> I'm aware of two possible ways of solving the problem:
> >>
> >> (1) Fix mod_dav, adjust mod_dav_svn accordingly
> >>
> >> (2) Reimplement PROPFIND in mod_dav_svn
> >>
>
> [...]
>
> > I'm not too happy
Daniel Shahaf writes:
>> I'm aware of two possible ways of solving the problem:
>>
>> (1) Fix mod_dav, adjust mod_dav_svn accordingly
>>
>> (2) Reimplement PROPFIND in mod_dav_svn
>>
[...]
> Wait a minute. Isn't "we have few active committers" a reason for
> choosing (1) over (2)? I would n
Evgeny Kotkov wrote on Wed, Dec 30, 2015 at 18:49:08 +0300:
> I'm aware of two possible ways of solving the problem:
>
> (1) Fix mod_dav, adjust mod_dav_svn accordingly
>
> (2) Reimplement PROPFIND in mod_dav_svn
>
> Doing (1) is hard, since it requires revving mod_dav's API and special care
>
13 matches
Mail list logo
