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?
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.
Received on 2011-04-14 21:04:00 CEST