On Thu, 14 Apr 2011 14:43 -0400, "C. Michael Pilato" <cmpil...@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? But, wait, svn_cmdline_* live in libsvn_subr, so they can't call functions implemented in libsvn_fs (not without another layer of indirection). Arrgh. > 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.
