(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 17:28:07 2002