Re: svn filesystem without Berkeley DBM?

On 7 Mar 2002, Jens Askengren wrote:

>
> I've several times heard the claim that the svn filesystem is an
> interface layer that could be implemented using for example a relational
> database or any other storage system.
>
> Why was Berkeley DBM choosen?

Given the choice of something or nothing, they chose something.

Quick, find a non-SQL or non-GPL'd SQL embeddedable server database that
supports transactions.

MySQL 4.x *might* fit the bill when it's done, but it wasn't released when
subversion started.

>Why not use regular files?
Define regular files.
I assume you mean text files like RCS (since otherwise, the files that
make up BDb are regular files).

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.

> much easier to maintain using regular tools, and possibly more
> robust(?).
None is true.

In particular, take CVS.

It uses RCS files.

There are few RCS file parsers out there (there goes your standard tools
since grepping them is pointless), none make it particularly easier to
manipulate the RCS files, etc.

Who needs to "maintain using regular tools" the CVS RCS files anyway?
The only tihng i've *ever* seen anyone do to them outside of use the cvs
client to access them is to restore them from a backup.

Grepping them is pointless, fer instance.
, Or does Berkeley DBM provides some features that simplifies
> the implementation?

Yes.
It supports transactions, recovery, etc, natively.

One *could* try to implement this stuff without some kind of real database
backend.

However, it's pretty pointless in reality.
--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 7 23:33:50 2002