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

Re: FS abstraction levels

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2004-04-01 16:56:07 CEST


>I was a bit schisophrenic, wasn't I? Stream-of-consciousness thingy. :-)
>What I meant was that it would be nice if all FS implementations could reuse the
>DAG logic, and that the easiest way to do that might be to move the vtable below
>the dag.c level rather than below the tree.c level.
I don't think it would be nice at all:-) I see the current tree and dag
code evolving into what I call a File System Abstract Provider and the
current BDB FS would be a concrete implementation of it. If I
understood Greg's FS_FS posts, he isn't confident that he will get much
code reuse out of the current tree and dag code.

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

I don't think "how much code reuse we can get" is a good metric to apply to this process. I'm not saying that the existing code needs to be re-written. Over time I see three (potentially four) Abstract Provider frameworks. Each could have more than one concrete implementation.

Hash map based
FS based
SQL based
and maybe something based on pure XML standards. However, my head spins every time I look at XML *standards* with respect to querying. This this is a big ol' dunno for me.


PS I exported my Word doc to HTML and ran it through a cleaner. It's a little hosed right now. So, I'll edit it a little and post it either today or tomorrow.

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