"Glenn A. Thompson" <gthompson@cdr.net> writes:
> I'm wondering how much abuse I will get if I refactor the fs.c, txn.c,
> and repos.c etc. code a little?
Depends if your changes are Good or Bad. Good changes earn praise.
Bad changes earn abuse like you've never seen, mister! :-)
> I'm looking at creating a vtable for most of the exposed fs functions
> exposed in svn_fs.h. It would be initialized by the create and/or open
> process.
> I want to add an optional svn_config_t parameter on the repos_create
> call. If it's NULL everything would be as it exists today. Minus the
> added indirection of course.
>
> I want to locate the vtable in the svn_fs_t structure. I'm struggling a
> little with what to do with DB specific references in svn_fs_t. I'm
> leaning towards (void*) baton cast at the "knowing" level.
>
> All the functions I see as having potentially different implementaions
> already take either svn_fs_t, svn_fs_txn_t, or svn_fs_root_t.
> svn_fs_txn_t and svn_fs_root_t already have references to svn_fs_t.
>
> I figure the exposed functions and any bdb related support functions
> would be renamed and moved to the bdb directory.
> The functions in (fs.c, txn.c etc) would be modified to call the moved
> code through the vtable. Maybe I could put all the "indirection"
> versions of the function in fs.c vs txn.c et al
>
> A single init function would be provided to "init" the table for those
> functions for each FS type. Much like the ra vtable works I believe.
> Functions like svn_fs_compare would stay where they are.
My brain is fried right now, but I'm guessing all of this is aimed at
getting some other type of database backend in place besides BDB?
> One thing that concerns me about the above is that it appears that cmike
> may have intended for folks to just implement the functions exposed in
> the bdb directory and link them in instead of the bdb implementation.
> Should the FS code be considered mutually exclusive? Was that the
> intent? There are still BDB specific includes and structure members
> referenced in the main libsvn_fs directory. Are there further plans for
> the abstraction work cmike has done?
C-Mike ... wait, that's me. *I* did the abstraction as a first step
toward supporting multiple database backends. I make no claims of
finality there. Yes, all the DB-specific stuff still outside the bdb/
subdir needs to be moved into the bdb/ subdir somehow.
If my fried brain is understanding what you are proposing to do, it
looks similar to my own plans. I had not yet resolved how to do the
database-type choosing though (whether it should a be compile- or
run-time option). In fact, aside from the bdb/ directory population,
I hadn't given the problem much more thought (and what thought I did
give is long lost now...)
I'd love to see a more detailed, longer-term proposition for what you
are planning to do!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 2 01:03:15 2002