[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Layering violations in the FS cache code? (was "svn commit: r1091573 - /subversion/trunk/build.conf")

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 14 Apr 2011 22:03:31 +0300

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


> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.