Suggestion for fixing DSO + global BDB cache badness

While chatting with my CollabNet cohorts on the phone a few minutes ago, and
hearing Garrett's tales of woe regarding the recent problems found in and
around the BDB caching code where DSO loading exists, something occurred to
me. So, by way of background, here's a brief walk through the discussion we
were having:

   * Garrett explains why DSO is a desirable (even cool) thing, and
     sympathizes with the stance that removing support for it is unkind.

   * The problem scenario is replayed: libsvn_fs_base is loaded, creates
     a global cache, and adds a bunch of cleanup routines to a global
     pool. Then the library is unloaded. Finally, the cleanups fire --
     only, there's no code behind them.

   * The first cut at solving this problem work for most cases, but fell
     over when accessing the FS layer via ra_local when ra_local was
     dynamically loaded.

At this point, I was compelled to ask: "Why do we every dynamically load
libsvn_ra_local? Or libsvn_fs_fs, for that matter?"

Here's my proposal. Only ever dynamically load libsvn_fs_base, and
libsvn_ra_dav, libsvn_ra_serf, on the premise that the primary reason we are
allowing dynamic loads at all is that we want to be able to provide packages
that are tied to externally dependent libraries like Berkeley DB, neon,
serf, etc. A DSO-enabled package with *none* of the optional DSO's would
still be able to use ra-local against an fsfs repository.

Of course, with the merge-tracking folks add SQLite to the mix, maybe we
want to continue allowing dynamic loads of libsvn_fs_fs -- that's fine with
me. But I can't think of *any* good reason to dynamically load
libsvn_ra_local, and am I especially proposing that we end that practice
today, if possible. Alas, I've not looked at the code to see how difficult
this would be.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand