On Sun, Apr 01, 2001 at 11:00:46PM -0700, Chip Salzenberg wrote:
> According to Eric S. Raymond:
> > What little you gain [from db] in performance you will lose in
> > multiplied difficulties and schedule slips because corruption will
> > be so much harder to detect and recover from.
> Now that you put it that way, I have to agree. Compare rpm's binary
> database with Debian's nice, readable directory tree + text database.
> Debian wins, hands down, in quality of implementation.
> OK, I'm going to fix the db problem by eliminating db. :-)
Kind of a reset here: please recognize that I believe we are seeing a crash
because we're doing something wrong. Not DB. It happens to occur in DB, but
that doesn't mean it is DB's fault. And we aren't seeing any data corruption
(for myself, the crash occurs during the Apache request cleanup phase, when
we toss memory; I believe it is a double-free somewhere)
Second: I totally support replacing db for a post-1.0 version of Subversion.
Or as a user-supplied patch / alternative. But we will never get a 1.0
shipped, any time soon, if we implement our own storage system. It just
After 1.0, I will *help* with replacing the DB backend. I'd like to see a
SQL backend in there. Some others want a pure-text backend. It should all be
possible. Our interfaces between the FS core and the databases feels pretty
trim at the moment, but we'll just have to see. (I believe we need to make
skel's a DB-specific thing, which means the impact could actually be pretty
But as Jim points out: please feel free. The software is definitely open for
change. I would also support (for the 1.0 release itself) any kind of
refactoring or introduction of APIs to enhance/improve pluggability of a
backend, assuming they aren't too costly to put in.
And lastly: welcome Chip! We met back in December when Dick Hardt and I came
to visit at VA Linux, but I never figured that we'd be running into each
other code-wise :-) Glad to have you here!
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:27 2006