Quoting Greg Hudson <ghudson@MIT.EDU>:
> I have developed a twelve-step plan for implementing the FS-backed FS,
> but I think I should slow down and worry about the abstraction issues
> first. So:
>
> In another thread, Branko asked:
> > Can someone refresh my memory as to why we'd need two abstraction
> > layers? I've been out of town for a while...
>
> CMike wrote (not in direct reply):
> > There has been some dispute over the necessity of [abstracting at
> > the libsvn_fs level]. I understand Glenn's defense of that
> > position, but think we need a few more knowledgable heads in the
> > circle before making that call.
>
> I'd like to generate consensus that:
>
> * It's necessary to abstract at the libsvn_fs API level for my
> project.
Hm, you're right, the FS back-end would be better split at the API level,
wouldn't it.
> * It's desirable to abstract the current BDB implementation at the
> storage level for future projects. (Perhaps this should wait
> until someone is actively interested in instantiating a second
> database-backed FS implementation, but I have no objections if it
> doesn't wait.)
Absolutely. I'm already interested in an Oracle back-end (or rather, if I had
one now, I could "sell" Subverison to a very, very, rich company...)
> * These two abstractions are orthogonal, and the storage abstraction
> has no bearing on my project.
Yes.
> * Documenting the FS schema as Branko suggests has bearing on the
> second abstraction, but not so much on the first. (Which is not
> to suggest that I want to depart from the general FS concepts,
> like nodes and node-copies and node-revs, but I think we already
> have those adequately documented in libsvn_fs/structure, mixed in
> with their representation. It's possible that I'm unclear on the
> meaning of "schema" as he's using it.)
Ah, yes. Well, I'm thinking both ways: a DB shcema for database back-ends, and
an architecture (nodes, revs, etc.) that API-level providers have to follow so
that their semantics are compatible with the rest of Subversion.
I'm almost completely convinced now that we'll have to expose the concept of
nodes even more publicly in the future, if we want to get more efficient working
copies and replicated or distributed operation. But that's in 2.0 land.
> My reasoning is that the storage abstraction assumes an underlying
> representation which can (a) efficiently support many small
> associations, and (b) support transactions. If you have underlying
> representation with these qualities, then there is no point in
> duplicating the code which maps FS concepts onto DB associations, but
> if you don't have those qualities, you'll want a representation with
> mostly or totally different algorithms.
Yup, your reasoning is sound -- as always. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 13:08:00 2004