On Thu, 2004-04-08 at 21:24, C. Michael Pilato wrote:
> Josh Pieper <jpieper@andrew.cmu.edu> writes:
> > If you put a vtable right at the svn_fs.h level, then every single
> > filesystem would have to re-implement tree.c. That's a big hunk of
> > code that is very error prone.
> I can't say that that reason alone is especially interesting to me.
> What do we do when someone else comes along and says they want to
> write libsvn_fs_gofigure(), and they have no use at all for any of the
> tree.c code? Our public API doesn't require that there even *be* a
> DAG subsystem -- this is an implementation detail of our initial
> shot at a versioning filesystem library.
> I think the thing to do here is to put the abstraction layer
> immediately below the existing svn_fs.h.
So, if I understand all this right, there are three possibly distinct
places to chop up libsvn_fs:
(1) At the API level
(2) At a level which lets libsvn_fs_fs reuse the DAG logic (tree.c)
(3) At the level appropriate for pluggable DB support
As I understand it, you are in favor of chopping at (1) now, (3) when
someone actually gets around to writing an SQL back end, and (2) never,
presumably because chopping up the current FS implementation in two
places would make it hard to maintain.
My question is: how far apart are (2) and (3)? I think I have seen some
argument over how much of the schema should be assumed by the
pluggable-DB abstraction layer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 10 04:58:53 2004