Re: FS abstraction levels

[Branko Čibej <br...@xbc.nu>]

Greg Hudson wrote:

>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.
>  
>
And probably the DAG abstraction, too. Maybe the API vtable should be at
the DAG layer, not the public FS layer.


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: FS abstraction levels

["Glenn A. Thompson" <gt...@cdr.net>]

Hey,

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

gat

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

Re: FS abstraction levels

[Branko Cibej <br...@xbc.nu>]

Quoting Greg Hudson <gh...@MIT.EDU>:

> On Wed, 2004-03-31 at 21:19, Branko Čibej wrote:
> > >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.
> 
> > And probably the DAG abstraction, too. Maybe the API vtable should be
> at
> > the DAG layer, not the public FS layer.
> 
> Does this count as a drive-by proposal?
> 
> For one thing, I can't tell what you mean.  Sentence one suggests I
> could reuse the code in dag.c (which I doubt), and sentence two suggests
> we should put the abstraction barrier at a level which allows multiple
> different implementations of dag.c (which I also doubt; tree.c appears
> to rely on the concept of transactions).

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.

No, I haven't the faintest idea how hard (easy?) that would be.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: FS abstraction levels

[Greg Hudson <gh...@MIT.EDU>]

On Wed, 2004-03-31 at 21:19, Branko Čibej wrote:
> >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.

> And probably the DAG abstraction, too. Maybe the API vtable should be at
> the DAG layer, not the public FS layer.

Does this count as a drive-by proposal?

For one thing, I can't tell what you mean.  Sentence one suggests I
could reuse the code in dag.c (which I doubt), and sentence two suggests
we should put the abstraction barrier at a level which allows multiple
different implementations of dag.c (which I also doubt; tree.c appears
to rely on the concept of transactions).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org