Re: FS refactoring.

Sorry for the delay in response to this... way too much happening right
now...

On Tue, Oct 01, 2002 at 06:10:54PM -0400, Glenn A. Thompson wrote:
> 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?

Depends on your definition of "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.

Gah! No way. The FS interface is the wrong level of abstraction. There is a
lot of code in FS to handle the DAG concept, to do merging, and other
behaviors. If you switch at the FS level, then every backend will need to
implement that stuff.

I would suggest that you start with Bill Tutt's model and go from there.
That diagram specifies the underlying concepts that we're operating with.
From there, we apply that model on top of BDB. Or a relational backend or
whatever.

The problem, of course, is that our current code organization and internal
concepts do not mirror the model well. And that is probably where
refactoring would begin.

(note: his model is conceptual; it isn't an E-R diagram like you would use
 for mapping onto a relational database;

 see: http://www.lyra.org/flytrap/SVNModel/
)

> 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.

Not sure. Would need to see this one.

> 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.

Have a complete structure which contains the vtable, and a companion pointer
for provider-specific data. That allows type-checking on the vtable stuff,
but retains the provider-private concept.

Any data outside of the vtable that is needed in "the new scheme" would just
go into svn_fs_t rather than a new sub-structure.

>...
> I figure the exposed functions and any bdb related support functions
> would be renamed and moved to the bdb directory.

Most are there already.

>...
> 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?

The bdb/ subdirectory was just a code move, not a refactoring. The only
references to BDB exist in that subdir. But the main directory still has
concepts which are BDB-specific (like its notion of keys/ids which are more
universally expressed as integers).

So a refactoring would move more stuff down into BDB, and possibly move some
stuff up *out* of BDB.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org