On 7 Mar 2002, 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.
>
> 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."
I meant as opposed to other DB's that support the needed features (of
which, not counting SQL databases, there are 0 that are open-source)
Not as opposed to some other substrate.
>
> 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.
Using a filesystem to implement this type of thing runs you into
portability and speed issues.
On portability, you also have to start worrying about simple bullshit like
case sensitivity, etc.
>
> > 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.
I do.
You effectively need to reimplement SCCS or RCS or something like it to
start with.
I can count the number of version control systems that did this that
support atomic transactions and recovery on one hand.
It's difficult enough to do it well that nobody does it.
It's just not worth the effort.
So if you think it's not that much work, i invite you to try it.
>
> (And, what's the portability argument about? Does Berkeley DB actually
> work on Windows?)
Try actually implementing it at a filesystem level and you'll see.
And BDB *does* work on windows, BTW.
>
> > 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
Received on Fri Mar 8 00:31:08 2002