Hey guys,
I'm wondering how much abuse I will get if I refactor the fs.c, txn.c,
and repos.c etc. code a little?
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.
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?
Please send wisdom along with any flames. I'm feeling the need for
some... Wisdom that is:-)
Thanks,
gat
PS As a fairly hardcore Denver Bronco fan who spent last night @ PSI
stadium in Baltimore, I'm a little flamed out. But what the heck, beat
me up some more:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 2 00:07:43 2002