On Wed, 2004-08-25 at 00:29, Eric S. Raymond wrote:
> Hello? Hello? Perhaps there is some subtlety I am missing here, but
> at least at first glance this design appears to have been air-dropped
> in from the Land of the Fucking Dumbshits.
Mmm, love that Eric Raymond diplomacy and charm. (In the future, please
refrain from using abusive or obscene language in this list.)
First, what you need to know: BDB recovery requires exclusive access to
the database; if other processes are accessing the database at the same
time, catastrophic lossage can occur. So, Subversion protects the
repository with a read/write lock; normal access gets a read (shared)
lock, while recovery gets a write (exclusive) lock. Thus, before
performing recovery, you need to make sure that all processes accessing
a Subversion filesystem have been killed off.
(I'd also like to know why the commit hung in the first place, but the
answer is probably buried in the BDB internals.)
Second, how we're improving things: in svn 1.1.0 (but not in 1.1.0-rc2,
I believe), when we grab the exclusive lock for recovery, we will do it
in a non-blocking fashion, and simply fail out if we don't get it.
We've also written a non-BDB back end which is less brittle; see
http://web.mit.edu/ghudson/info/fsfs.
Third, a philosophical point: we all care about usability, but it is
pointless to rant abusively about a non-usable aspect of a piece of
software without understanding the constraints which lead to it being
unusable. Perhaps the user does not care about the constraints, but the
developers do, because the developers have to address those constraints
in order to fix the problem. BDB does not give us progress indications
during recovery. Printing a timestamp at the beginning would be a
useless bandaid. Writing a back end which doesn't rely on a brittle
database library is a big undertaking, and while we've done it, it took
time to do, and will take more time to test thoroughly enough to make it
the default.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 25 07:05:41 2004