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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 1 19:27:49 2004