Hey,
Greg Hudson wrote:
> First, to dispel a small myth: Subversion does not currently have a
> pluggable filesystem architecture. We have a separation between
> libsvn_repos and libsvn_fs, but no logic for deciding between several
> implementations of libsvn_fs. We have an API for libsvn_fs which could
> be reimplemented, but it exposes concepts like node IDs which mostly
> constrain the implementation to something sitting atop a lookup
> database. These problems are expected to be corrected after Subversion
> 1.0, but nobody should assume that we're already there.
>
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?
For the record I don't have a problem with Berkely DBM. I think it was a
good choice. For reasons related to my application I feel mySql is a better
choice for me.
One last thing, is there an article in which Linus outlines where he feels
Subversion is deficient. Just curious.
Glenn
>
> On Thu, 2002-03-07 at 17:32, Daniel Berlin wrote:
> > > Why was Berkeley DBM choosen?
> >
> > Given the choice of something or nothing, they chose something.
>
> I'm a little tired of this refrain. We chose to use a lookup database
> with transactions as our substrate, instead of a filesystem interface or
> other substrate. Those are both "somethings."
>
> It may be that our part of the work was a lot easier using the BDB
> substrate, but I have my doubts. If we were using the filesystem
> interface as a substrate, we would not have started out by implementing
> a lookup database with transactions, certainly; we would have found a
> way to map a repository onto the filesystem and get "transactions" out
> of atomic filesystem operations. I have some ideas in my head about how
> that could work (and I've commented on them on this list), but they're
> not fully fleshed out.
>
> > Given that, the answer is because it wouldn't be
> >
> > 1. fast enough
> > 2. portable enough
> > 3. support atomic transactions
> > 4. support recovery
> > without a whole lot of work.
>
> I don't think it's really a whole lot of work to get those things; not
> substantially more than we put into the current implementation.
>
> (And, what's the portability argument about? Does Berkeley DB actually
> work on Windows?)
>
> > In particular, take CVS.
> >
> > It uses RCS files.
>
> We would obviously not want to use the RCS format; it would be a
> terrible mismatch for our semantics. We have a simpler model for files
> and a more complicated model for directories.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 8 16:47:19 2002