Thanks for the response.
shoooo I'm out of town in NYC and we lost our T lines here for over four hours.
I'm going to continue on with my internal development as long as possible. But
assuming I don't get pulled in another direction I will want to give a sql
based fs a try.
Does the list have some sort of collective opinion on how they would like to
see "function" indirection implemented?
You mentioned a vtable. Did you have something specific in mind?
Thanks,
Glenn
Greg Hudson wrote:
> (I'm trying out a new MUA; apologies if this mail shows up in HTML or
> something awful like that.)
>
> Glenn Thompson wrote
>
> >Any idea as to how much the svn_fs API will change for 2.0?
> >
> >The reason I ask is that I want to use Subversion to store largish amounts
> >of binary data. 50+ GB in 100-500KB files. For my situation I want to use
> >mySql InnoDB. I'm guessing that I will use multiple repos. Although, any
> >given repo could easily reach 5-10GB.
> >
> >If I implement a sql svn_fs that implements the 1.0 API, will I have major
> >work to get it plugged into 2.0.
> >
> Well, you won't be able to just implement the 1.0 API without doing some
> work on the surrounding code; as I said before, there is currently no
> logic for selecting between libsvn_fs implementations. (The fs creation
> functions have names like svn_fs_open_berkeley(), but you can't just
> slip an svn_fs_open_sqldb() alongside that because the "work functions"
> like svn_fs_make_dir() are just regular functions implementing the
> Berkeley DB back end; they don't make a call through a vtable or anything.)
>
> As for how the API might change: I suspect it will mostly stay the same,
> except that the concept of node IDs may become internalized, which would
> cause operations like find_nearest_entry() to move inside the FS
> interface. I don't expect that change would be seriously traumatic.
>
> >One last thing, is there an article in which Linus outlines where he feels
> >Subversion is deficient. Just curious.
> >
> He doesn't want to have to change his work habits significantly to use a
> version control system. Larry was willing to go to significant effort
> to make Bitkeeper fit that requirement, but really, if nobody has to
> change their work habits to use a tool, then the tool has to be very
> complicated. On the other hand, tools like Aegis haven't caught on
> because (I believe) they try to constrain people's habits too much.
> Subversion is based on the CVS operational model because we know the
> CVS model is adequate for (and familiar to) lots of people, particularly
> people doing open source projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 8 21:59:34 2002