[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS: Plan of attack

From: Josh Pieper <jpieper_at_andrew.cmu.edu>
Date: 2004-04-09 02:56:16 CEST

On Thu, Apr 08, 2004 at 07:41:54PM -0500, C. Michael Pilato wrote:
> > This would be the top level abstraction, i.e. implementing a tree
> > structured filesystem on top of the DAG. There would still be a
> > need for another abstraction for different database backends.
> Have we reached consensus on whether the top-most FS abstraction would
> be immediately below svn_fs.h or immediately above dag.h? If the
> answer is, "Yes, immediately above dag.h", then the answer is false,
> because I think that the svn_fs.h should be converted to mostly one
> (or two) big fat vtables and some init functions. If people want to
> rewrite filesystem libraries, let 'em rewrite the whole thing, because
> next week someone else is going to come along and want the abstraction
> moved up a little higher.

If you put a vtable right at the svn_fs.h level, then every single
filesystem would have to re-implement tree.c. That's a big hunk of
code that is very error prone.

> > So my proposal is to create a branch, say called
> > 'libsvn_fs_fs_abstraction' where this prototype implementation of
> > libsvn_fs_fs can live. Once we have it (or during the process of
> > creating it), we decide on a good abstraction layer, then
> > libsvn_fs_fs can be re-implemented to meet that abstraction.
> As Karl noted in his reply, there's no reason to branch unless you
> know you'll be conflicting with other libsvn_fs_fs work.

Ok, that seems to be the consensus, so that's the route I will go.

> If I'm understanding your proposal correctly, none of this involves
> changing a single line of code in libsvn_fs, right?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 9 02:56:32 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.