On Jul 5, 2005, at 3:12 AM, Christoph Bartoschek wrote:
> Am Dienstag 05 Juli 2005 03:52 schrieb Ben Collins-Sussman:
>
>
>> 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.
>>
>
> Does this also hold when one uses a svnserve daemon? Currently all
> our users
> go through svnserve. Does this also mean that there are N different
> programs
> using the database? I thought svnserve is something like the
> mysqld which
> serializes access to the database.
>
svnserve is acting as a *network* gateway, perhaps... but there's
nothing preventing some other program linked to libsvn_fs from
accessing the repository as well. For example, you might have a hook-
script that runs 'svnlook'. Or a user with a shell on the system
might run 'svn checkout file:///'.
The point is that there's no ueber-process guarding the health of the
tables themselves. Instead, there's a bunch of libsvn_fs processes
potentially all accessing the repository at once -- svnserve,
mod_dav_svn, svn, svnlook, svnadmin -- all equal peers, all unaware
of each other. Any one of these programs could wedge the database,
and none of the programs knows how to detect this and un-wedge.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 14:35:41 2005