Greg Hudson wrote:
> When I wrote the FS abstraction code, I deliberately introduced some
> circular dependencies between the FS modules and the loader library,
> figuring that it would work out as long as the loader library
> consisted of only one source file.
>
> Well, that castle has apparently come crumbling down; reportedly,
> Windows doesn't allow shared libraries to have undefined symbols, so
> you can only have circular references with a static build.
>
> The circular dependencies consist of:
>
> * The node-rev ID functions, some part of the svn_fs API and some
> internal, which (as previously mentioned) are implemented in the
> loader library.
>
> * A utility function svn_fs__canonicalize_path, which I happened to
> notice when making a pass over libsvn_fs_base (because it was in
> fs.c, which I devoted more attention to). It's not a tremendous
> amount of code, but it's possible that there are other
> FS-independent internal utility functions which could be factored
> out.
>
> Here are possible solutions:
>
> * Introduce a fourth library, libsvn_fs_util, containing the
> node-rev ID functions and svn_fs__canonicalize_path.
>
> * Stuff these functions into libsvn_subr, using internal names.
> (Same idea as the previous one, trading off scope elegance against
> the overhead of creating a new small library.)
>
> * Move svn_fs__canonicalize_path back into the individual filesystem
> modules and work harder at vtable-izing the node-rev ID functions,
> so that there is no need for circular dependencies. I made two
> proposals on how to do this in
> http://www.contactor.se/~dast/svn/archive-2004-04/1461.shtml,
> although none of them are terribly attractive.
>
> * When loading the FS module, pass a pointer to a vtable containing
> the node-rev ID and utility functions located in the loader
> library.
>
> * Move svn_fs__canonicalize_path back into the FS modules, and
> simply duplicate the node-rev ID functions (using internal names)
> in each FS module. When svn 2.0 rolls around and we can
> vtable-ize the node-rev ID functions the easy way, we can
> eliminate the loader library implementation of those functions.
>
> Preferences? I think I side with the last option at the moment, but
> my opinion is fluid.
I favour libsvn_fs_util, mainly because I'd already started in that
direction before Greg's email, but also because duplicating the code in each
fs module seems a little messy.
Attached is a first draft patch, although I've called it libsvn_fs_subr.
Also note that the initialization functions should take an ABI version, like
the ra modules do, but that's a minor point, and I'm out of time for
tonight.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 2 00:21:03 2004