On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote:
> The code in question has evolved over many months so it is
> very possible that the name of svn_fs_get_cache_config()
> and friends is no longer appropriate. The same goes for the
> place that this has been implemented.
>
> From a design perspective, I think it is perfectly to o.k. to
> expose resource limits on the server UI level. The fact that FSFS
> is currently the only part of the server that uses these settings
> does not change, IMO, the fact that they are part of the UI.
I don't have an opinion about exposing resource limits via the server UI. I
do have a strong opinion about the code honoring the flow of the layered
library design we have. If you want to tweak server settings from client
code, you need to do so via the RA vtable(), implementing the logic to do so
(or to expressed *not* do so) in every RA provider.
On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote:
> Maybe we should simply move the function in question to libsvn_subr
> and rename them properly.
On 04/13/2011 11:12 PM, Daniel Shahaf wrote:
> I assumed the resolution would be to move that function to libsvn_fs, not
> to libsvn_subr...
I'm honestly not quite sure exactly where the right place is. I don't
really see what moving it to libsvn_fs does for us -- IMO, it's still wrong
for svn_ra_initialize() call into that. (libsvn_ra should only call into
libsvn_subr, libsvn_delta, and its own RA provider vtable.) If we move it
all to libsvn_subr -- the common-most utility function we have to offer -- I
would suppose that that would solve this. But again, I don't understand the
code, it usages, or its requirements in terms of thread-safety and such.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-04-14 20:43:49 CEST