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

FS abstraction, for real this time

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-04-24 22:55:55 CEST

Since Josh and I (mostly Josh) now have a fully armed and operational
FSFS implementation, we'd like to implement the FSAP abstraction part
of gat's document
(http://www.cdrguys.com/subversion/htmlPluggable/Pluggable3.htm; focus
on Appendix C and ignore types with "_bl_" in the name) so that it can
live in the same executable as the BDB implementation. This means:

  * The existing BDB implementation becomes the "baseline" (bl) FSAP.

  * The FSFS implementation becomes the "fsfs" (fs) FSAP.

  * The three abstract filesystem objects (svn_fs_t, svn_fs_txn_t, and
    svn_fs_root_t) have most of their contents removed in favor of
    FSAP-specific vtable and private-data fields.

  * The libsvn_fs API functions (or at least most of them) change to
    do their work through the vtable.

Although it would be possible to implement all of this inside one big
happy library, I'm thinking that three separate libraries (loader,
baseline, FSFS) is probably the right answer. If the loader supports
dynamic linking, then a binary packager can split up the FS back ends
into separate packages so that the main Subversion package doesn't
depend on BDB, just as the Mandrake packages currently do with the RA
layers in order to avoid having the main Subversion package depend on
Apache. I'm willing to be convinced otherwise, though.

One question I'd like to settle:

  * Should we have three separate libraries for the loader, baseline
    implementation, and FSFS implementation, or should we have one big
    happy libsvn_fs directory with "baseline" and "fsfs" subdirs? The
    former is more flexible for binary packagers (if the loader has
    dynamic linking support, packagers can separate out the FS back
    ends into separate packages like some of them do with the RA
    implementations); the latter is simpler.

Once that is decided, I'd like to create a new branch (the existing
pluggable-db branch doesn't appear to have any work on it relevant to
the FSAP abstraction) and start working. I'd like license to depart
from gat's document on the following points:

  * No infiltration of FSP-level concepts into the three abstract
    filesystem objects. Specifically, in svn_fs_t, fsp_name should be
    fsap_name, and it should be made clear that the pdata field
    belongs to the FSAP, not to the FSP. (I think the latter was
    gat's intention, but his comment is unclear.)

  * Field names. Sometimes I think he abbreviated too far. fsp_nm
    becomes fsp_name, fv becomes vtable, pdata becomes fsap_data.

  * Type names. He used svn_fs__ prefixes on private type names. We
    only need the svn_fs__ prefix on exported (but private) function

  * Constructor functions (fs_vtab_t->{begin_txn/open_txn},
    txn_vtab_t->txn_root) should not have pdata arguments, as far as I
    can tell. I don't know how the loader would decide what to pass
    there, and the implementations should be perfectly capable of
    filling in the fsap_pdata field on the returned objects.

Comments? I may forge ahead with this plan without waiting long
enough for feedback, but what is done can be undone, particularly if
it's done on a branch.

(In case anyone is wondering what happened to the "maybe we should
abstract at the DAG layer instead of at the API layer" thread, I think
Josh wound up making enough changes to the tree.c functions that such
an abstraction doesn't really make sense.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 24 22:56:18 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.