Greg Hudson <ghudson@MIT.EDU> writes:
> I'd like to generate consensus that:
>
> * It's necessary to abstract at the libsvn_fs API level for my
> project.
I can't say if this is true to not; I *can* say that it's a crying
shame that you'll basically be reimplementing the entire libsvn_fs.
But GAT and others agree that this level of abstraction is needed, and
I have no strong feelings that they are wrong.
On a technical note, I assume we're looking at an RA-ish abstraction.
libsvn_fs becomes a loader library for libsvn_fs_db (which in turn
plugs into libsvn_fs_bdb and libsvn_fs_oracle and ...) and
libsvn_fs_fs ?
> * It's desirable to abstract the current BDB implementation at the
> storage level for future projects. (Perhaps this should wait
> until someone is actively interested in instantiating a second
> database-backed FS implementation, but I have no objections if it
> doesn't wait.)
+1. And if you don't need this abstraction right now, then by all
means it can wait until it *is* needed.
> * These two abstractions are orthogonal, and the storage abstraction
> has no bearing on my project.
Absolutely. In fact, once you have the API abstraction in place, the
secondary abstraction becomes a feature of libsvn_fs_db, not of
libsvn_fs. Your fs_fs module likely won't even have such a secondary
abstraction, right?
> * Documenting the FS schema as Branko suggests has bearing on the
> second abstraction, but not so much on the first.
Absolutely.
> Earlier, CMike wrote:
> > I'll gladly wrangle libsvn_fs into the necessary state to allow for
> > pluggable backends.
>
> Does this extend to working on the top-level abstraction, assuming we
> do that, or should I treat that as a separate change?
I think I should've said "I'll gladly help to wrangle..." :-)
But yes, I'll make myself available to work on both tasks. And as I
noted above, the top-level abstraction appears now to be the only one
currently in-demand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 17:01:13 2004