[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

FS abstraction and circular dependencies

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-05-01 19:27:30 CEST

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

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

  * 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.