Hey,
>I'd like to generate consensus that:
>
> * It's necessary to abstract at the libsvn_fs API level for my
> project.
>
Totally!
>
> * 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.)
>
I'd like to see (at least) the design work done at the same time.
Mainly because it will force us to think about more issues up front.
>
> * These two abstractions are orthogonal, and the storage abstraction
> has no bearing on my project.
>
Yup!
>
> * 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.)
>
I haven't read the structure docs in a while. The last time I did, it
was a little out of date. I assume they were updated in the last year? :-)
Before you guys go any further on these. I'd like to beg folks to read:
http://www.cdrguys.com/subversion/Pluggable3.doc
While my writing may be less than stellar, I give a fair amount of
thought to the abstraction.
I also want to point out that a logging system is long overdue. My
pointer marshaling wasn't *that* bad as a temp fix to the BDB short comings.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 15:25:39 2004