C. Michael Pilato wrote:
>Greg Hudson <ghudson@MIT.EDU> writes:
>
>
>
>>It does appear that there are two different levels where an FS
>>implementation might wish to diverge from the current one--at the
>>libsvn_fs/bdb level of making associations, or at the more abstract
>>libsvn_fs level. Interestingly, kernel filesystems have the same
>>problem; at least in *BSD, a lot of ufs code is shared between several
>>filesystems (ffs, mfs, lfs, ext2fs) but there is also a higher-level vfs
>>abstraction used by more radically different filesystems like nfs.
>>
>>
>
>Glenn Thompson's design calls for modularity at both locations:
>
> 1. directly beneath the public FS API, and
> 2. and the back-end storage interface.
>
>There has been some dispute over the necessity of the first of those.
>I understand Glenn's defense of that position, but think we need a few
>more knowledgable heads in the circle before making that call.
>
>
Can someone refresh my memory as to why we'd need two abstraction
layers? I've been out of town for a while...
>>I don't care much whether we do the work on a branch or on the trunk
>>with a disabling #ifdef. One requires more merging work and one
>>potentially puts vestigial code into releases (or requires us to remove
>>code in dist.sh, which some might find distasteful), but neither cost is
>>very high.
>>
>>
>
>I prefer this work be done on a branch. Merging isn't scary,
>navigating around #ifdefs is annoying, and doing magic code removal
>tricks in our distribution script is silly.
>
>
+1 to the Nth power.
By the way, before we jump into refactoring and abstracting, there's one
thing we have to do that should've been done ages ago, only we didn't
know enough to do it.
And that is, formally document the FS schema.
/me waits for the angry shouts to stop
My point is that we never defined a relational schema for the FS. Sure,
that's because we're not using a relational DB backend. However, the
time is coming when we _will_. So we now have to define this schema, and
define how it maps to our BDB implementation, skels and all (that part
is documented, thank goodness). If nothing else, the various sql
back-ends will then be able to use the same schema, making it much
easier to write database-independent query tools.
We used to have something that Bill Tutt produced, but I hope reality
isn't as complicated as that...
--
Brane Čibej <brane_at_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
Received on Wed Mar 31 00:11:24 2004