subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgeny Kotkov <evgeny.kot...@visualsvn.com>
Subject Re: [RFC/PATCH] Handling PROPFIND in mod_dav_svn (was: Re: Issue with browsing a SVN 1.9.2, schema 7, packed, repository)
Date Fri, 29 Jan 2016 14:37:28 GMT
Daniel Shahaf <danielsh@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

Mime
View raw message