[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC/PATCH] Handling PROPFIND in mod_dav_svn (was: Re: Issue with browsing a SVN 1.9.2, schema 7, packed, repository)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 31 Dec 2015 00:37:33 +0000

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

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 ☺


Received on 2015-12-31 01:37:53 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.