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

Re: svn filesystem without Berkeley DBM?

From: Glenn Thompson <gthompson_at_cdr.net>
Date: 2002-03-08 16:46:24 CET

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

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.