databases for the FS (was: Re: First impressions...)

On Sun, Jan 27, 2002 at 02:56:47PM +0100, Marcus Comstedt wrote:
> Barry Scott <barry.alan.scott@ntlworld.com> wrote:
> > Using a database is far more powerful then using a file system.

You betcha.

> > Being able to use SQL to query the repository is a good solution
> > to building the more complex SCM solutions on top of SVN.

Yup. There are a lot of interesting things you can do once you have SQL's
query facilities.

> > My guess would be that folks that want the database backends
> > have tackled complex SCM problems and know why the simple interfaces
> > to meta data have problems. Speed of query across large sets of
> > versions and files being one.

Well, not really in my case. I'd like to see it simply for some of the
queries that I'd be interested in. Also, while thinking about ACLs last
year, and realizing that the application of ACLs in a versioned filesystem
with copies would be amazingly difficult without some query facilities.

> Don't make the mistake of puting an == between "SQL" and "database".
> SQL implies a _relational_ database, which I think is totally out of
> place here. A hierarchical or object database seems far more
> appropriate.

I would prefer the relational database myself. It would be easier to answer
questions like:

"which files have the 'graph-input' property set on them?"
"what revisions were committed by 'gstein'?"
"in the revisions that gstein changed between 100 and 200, what files were
touched?"

etc.

It is rather difficult to formulate adhoc queries against hierarchical or
object databases. Although I do recognize that is because there isn't a
standardized query language like what SQL has done for relational databases.

I don't see hierarchical as working (although I could probably learn more
about them). Object databases could work, I'd think. But that missing query
language...

In any case, Subversion 2.0 will have an extra layer in the FS. One layer
for the FS semantics, and one layer for storage. The interesting part will
be coming up with an API between those two layers which provides for simple
key/value storage like the Berkeley DB we have today, provides for
relational (SQL) databases, and for the N different things people can think
of (including object databases). I have a sneaky suspicion that it will be
difficult to craft an API which doesn't impose unwelcome constraints upon
the storage medium or assume a particular model.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org