On 14.04.2011 21:03, Daniel Shahaf wrote:
> On Thu, 14 Apr 2011 14:43 -0400, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>> 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.)
> Would svn_cmdline_init() be a better place to call the init
> function from?
Clearly not, since that function is a startup helper for command-line
programs, not for libraries.
-- Brane
Received on 2011-04-14 22:32:51 CEST