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
> for other modules using it.
>
> I believe that currently we don't have the necessary resources (aka
> committers)
> to do that. Given that the problem exists since 2003, I also doubt that it's
> going to solve itself in the nearby future. And moreover, even if somehow
> managed to do that, the fix would probably only be available in the newer
> 2.6.x httpd releases.
>
> With that in mind, I propose we do (2).
Wait a minute. Isn't "we have few active committers" a reason for
choosing (1) over (2)? I would naïvely expect "rewrite it" to be more
expensive to implement/maintain than "patch it".
Similarly, playing devil's advocate, if the issue exists since 2003,
then presumably it's not urgent to fix, and waiting until httpd-2.6 is
released might not be a major setback.
("Is not going to solve itself" is avoidable rhetoric: of course it's
not going to fix itself, somebody is going to have to develop a mod_dav
patch.)
So these are three points in favour of (1) rather than (2). What are
the reasons for (2) over (1)?
> Apart from solving the memory usage issue, having the PROPFIND implementation
> in mod_dav_svn would allow us to improve a couple of other aspects of how we
> handle these requests, e.g.:
>
> - Shrink down the PROPFIND response size by avoiding duplicate xmlns:
> namespace declarations that currently exist.
>
> - Optimize how we retrieve properties from the FS layer, since we would
> no longer be doing mod_dav - mod_dav_svn - mod_dav transitions, and
> would have more flexibility.
Are these significant? How much faster will a checkout/update be if
these improvements were implemented? Would it be possible to implement
in httpd-2.6 mod_dav features that would achieve comparable performance
(when mod_dav_svn is run under httpd-2.6)?
> As far as I know, those modules don't have tests
> and not breaking their behavior could be a challenging task.
>
You might want to double-check that with the httpd-dev crowd. IIRC
httpd has some of its 'make test' functionality out-of-tree.
Or ask breser; I know he ran into this problem (changing
mod_dav/mod_dav_svn without breaking mod_dav_fs) and he might have found
a solution.
> Although I'm not entirely happy with reimplementing a part of the protocol, I
> don't think that there are other realistic approaches to this serious problem.
> It wouldn't be the first time we're doing something like this, since we
> already
> handle POST ourselves, as well as provide the custom Subversion's HTTPv2
> protocol implementation.
>
Tangentially: We should find a new name for our POST-based protocol;
"HTTPv2" means something else to the wider world.
> I attached a proof-of-concept patch that does (2). This patch solves the
> memory usage problem in my experiments and passes HTTPv2 / HTTPv1 tests.
>
> Thoughts?
I'm not too happy at basically saying I prefer (1) over (2) when you've
already written a 2000-line patch for (2)... but maybe (2) _is_ the
better way to go and I just don't see it yet. Enlighten me ☺
Cheers,
Daniel
