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."
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
Received on Fri Mar 8 00:05:18 2002