You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/04/24 20:55:55 UTC
FS abstraction, for real this time
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
names.
* 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
Re: FS abstraction, for real this time
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 24, 2004 at 04:55:55PM -0400, Greg Hudson wrote:
> 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.
You mean to avoid depdencies on berkeley db and neon...
The DSO for the Apache modules (which also end up in separate packages)
avoid an Apache dependency, but that's a different example.
At any rate I strongly support this. It makes my life so much easier.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FS abstraction, for real this time
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Greg,
<understatement>You made my day!</understatement>
Greg Hudson wrote:
>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.
>
Makes sense to me.
>
>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.
>
I was thinking the former, but for no real reason that I can recall. So
I have no real opinion either way.
>
>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.)
>
>
Yes the later was my intention.
> * Field names. Sometimes I think he abbreviated too far. fsp_nm
> becomes fsp_name, fv becomes vtable, pdata becomes fsap_data.
>
>
I'm totally fine with the long names.
> * Type names. He used svn_fs__ prefixes on private type names. We
> only need the svn_fs__ prefix on exported (but private) function
> names.
>
Yup.
>
> * 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.
>
>
Hmm, I thought I had a good reason for pdata arguments. I'll see if I
can dig up my reason. But like you say below, it can be changed if
needed later.
>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.)
>
>
Thanks for taking this on!
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FS abstraction, for real this time
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> 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.
Yay!
> 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.
Yes.
> (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.)
I was, indeed, wondering what happened to this thread -- thanks for
clarifying.
Sorry I'm too busy drowning in other tasks to help out. But if you
have questions, feel free to hit me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FS abstraction, for real this time
Posted by kf...@collab.net.
Mike Pilato is out for a couple of days -- visiting family, but due to
circumstances beyond his control doesn't have the Net connectivity he
expected. I know he'll want to comment in this thread, but he
probably won't be able to until Wednesday.
Just FYI,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FS abstraction, for real this time
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-04-24 at 16:55, Greg Hudson wrote:
> Although it would be possible to implement all of this inside one big
> happy library, I'm thinking that three separate libraries [...]
[...]
> * 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[...]
Whoops. If anyone noticed that I was being more long-winded than usual,
the question form of that issue was meant to have been edited out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org