On Jul 5, 2005, at 9:52 AM, Ben Collins-Sussman wrote:
>
> On Jul 4, 2005, at 8:31 PM, Adrian Hoe wrote:
>
>
>>
>> But reliability is more then easy integration/setup. We have
>> systems running on MySQL with more than 250 tables and over 7
>> millions tuples and not crashing at all.
>>
>
> Are you aware that mysql uses BerkeleyDB for transacations? :-)
I read about that sometime ago but did not really paying attention to
it. We use database and development application on it. The internal
engine is not our focus. Thanks for the information.
> Actually, your mysql database probably has crashed many times, but
> you don't notice. That's because the 'mysqld' process is a single
> point of access for all programs; if the database gets
> inconsistent, mysqld stops serving all requests, recovers the
> database, then things move on smoothly.
We noticed that. This layer is transparent to users. At users
context, the database does not crash.
> The big problem between svn and BDB is that we didn't do it this
> way: there's no single 'svnd' mediating all access to the tables
> and keeping guard over database health. That's the model that
> BerkeleyDB expected we'd follow, and we didn't. Instead, we have N
> diferent programs all using the database (via library linkage), and
> when one program wedges the database, all the others sit around and
> get stuck waiting... or error out. Rather than a daemon
> automatically noticing the problem and recovering, a human has to
> step in and recover things.
>
> So our big mistake here was not realizing how 'brittle' (easy to
> wedge) BDB would be, in the absence of a central daemon.
What is the reason for subversion development team to choose this
unstable (unstable or error prone?) implementation?
--
"If you missed the rising sun and the morning dew, don't miss the
beautiful sunset." -- Adrian Hoe inspired by Michal Nowak, June 15 2004
http://adrianhoe.com
Received on Tue Jul 5 04:21:52 2005