I think you may have misunderstood the issue, but I realized that I can
make life a lot simpler by having svn_fs_create look for an FS type from
the caller ("bdb" or "fsfs") rather than an FSAP name ("base" or
"fsfs"). Then the smarts can live in the loader library.
On Tue, 2004-04-27 at 21:01, Glenn A. Thompson wrote:
> > * Introduce an svn_fs API (implemented in the loader library) to do
> > the translation. I'm a little reluctant to do so at this time
> > because it would require building in a little more of the
> > FSP-abstraction infrastructure, and as Garrett has pointed out, it
> > sucks to have infrastructure with nothing built behind it.
> I don't understand how there's "nothing built behind it" if it
> facilitates dynamic installation of two existing implementations (Base
> and FSFS).
There's something behind the FSAP-level abstraction. There's nothing
behind the (unimplemented) FSP-level abstraction.
> I want to use the svn_config_t structure as the configuration center
> piece. The plan was to pass one in on the create call.
That seems totally orthogonal. The existing API already (and the
extensions I made to it) already provide a config hash; using an
svn_config_t instead might be nice for namespace reasons, but is totally
unnecessary at the current time.
> couldn't we use "repos templates" to install a config file somewhere,
Do we even have repos templates any more? At any rate, this is
unnecessary. The issue was not how to communicate the necessary
information to svn_fs_create, but how a user-specified FS type
("bdb"/"fsfs") should be mapped to an FSAP name ("base"/"fsfs").
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 28 04:51:16 2004