[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: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Fri, 29 Jan 2016 17:37:28 +0300

Daniel Shahaf <danielsh_at_apache.org> 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 should
just go with (2) and have the problem solved. But since we were unable to
agree on that, this issue is now tracked as SVN-4616:

  https://issues.apache.org/jira/browse/SVN-4616

One thing worth adding is that there's also a problem with how we log actions
from mod_dav_svn callbacks.

Within a callback, we lack the information about the state of the operation.
As one example, deadprops.c:db_first_name() calls dav_svn__operational_log().
While handling <allprop/> depth 1 PROPFIND requests, db_first_name() is called
once per every walked entry. Every subsequent call rewrites previously set
r->subprocess_env values. Hence, the actual log entry is determined by the
last walked entry, and that's incorrect. And all these values are allocated
in the request pool, thus triggering unbounded memory usage.

I think that this part of the problem can't be solved properly without
reimplementing the PROPFIND in mod_dav_svn.

Regards,
Evgeny Kotkov
Received on 2016-01-29 15: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.