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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 20:07:29 2004