On Wed, 2004-03-31 at 08:56, C. Michael Pilato wrote:
> > * 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.
I don't think I can reuse much of an implementation that maps FS
concepts to DB concepts. Though there may be some stuff that can be
factored out, particularly in the realm of auto-merging.
> 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 ?
Yes, that sounds right. (That's perhaps more like svn_stream than like
svn_ra from the caller's point of view.)
There may also be a place for utility functions shared by all the FS
implementations, which don't belong in libsvn_subr. Those could live in
libsvn_fs itself if there's no issue with circular function
dependencies.
> 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?
Right. You can imagine that the second layer of abstraction for
libsvn_fs_fs is the operating system's filesystem abstraction
(apr_open/apr_read/apr_write). If there were an OS interface for
transactional DB-like functionality, we wouldn't need a second layer of
abstraction in libsvn_fs_bdb.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 21:38:49 2004