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

Re: FSFS: Plan of attack

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-04-10 17:46:36 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> 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.

Right. I just don't see the need for 3 divisions.

> 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.

That question isn't easy to answer because today there is too much
bleed of BDB-isms into the upper layers. Until we can purge dag.c and
tree.c of those BDB-isms, it'll be hard to say where the right break
is.

My gut feeling, though, is that the pluggable-DB abstraction API must
necessarily define at least a basic schema. There will be notions of
things like revisions and transactions and nodes. Those thing will
have piece of information associated with them which can be used to
determine the relationships between them. Functions are going to
accept certain parameters and return certain values. You see where
I'm going.

I don't know right now what the final API will look like. It's
possible that (2) and (3) are closer than I think. We'll try to keep
that API as vague as we can without going mad, and try to define
relationships between first-class schema objects without defining
their storage and retrieval mechanisms, and hopefully without
destroying any hopes of great performance from all the available
backends. That's the goal of the exercise.

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