As I pointed out in email earlier this week... I never suspected a problem
with Berkeley DB, but in how we were *using* it. The fix below proves that
supposition.
So... to everybody that is all gung-ho on tossing binary files, this
certainly is *not* an example case for doing so, and it never was. We saw a
crash that had DB on the call stack, but not because DB screwed up. (heck,
in my case, DB had completed all its work and crashed at request cleanup
time).
Further, I will posit that if somebody wants to go and build a text-based
database, then they're going to be seeing crap like this for the next year.
Let's not forget that Berkeley DB has been in development for *YEARS*. I
simply won't trust somebody who says, "check this out. a text database for
SVN!"
I was near to a time-out on this whole thread, but Brian beat me to the
punch. We are using Berkeley DB for Subversion 1.0. Done. Fini.
It isn't because we love binary formats, or hate text formats. We're doing
it because it has the features and stability that we need. And holy crap...
it means that we don't have to code the damned thing ourselves!
Ask yourself this, would you like Subversion in a few months on Berkeley DB,
or would you like it sometime end of next year on a text database?
Cheers,
-g
On Thu, Apr 05, 2001 at 07:16:37PM -0000, sussman@tigris.org wrote:
> User: sussman
> Date: 01/04/05 12:16:37
>
> Modified: subversion/libsvn_fs nodes-table.c
> Log:
> (svn_fs__new_successor_id): remove erroneous svn_fs__track_dbt()
> call, which fixes the double-free() bug.
>
> Submitted by RADICS Peter <mitch@lbcons.net>.
>
> Revision Changes Path
> 1.19 +0 -1 subversion/subversion/libsvn_fs/nodes-table.c
>
> Index: nodes-table.c
> ===================================================================
> RCS file: /cvs/subversion/subversion/libsvn_fs/nodes-table.c,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -r1.18 -r1.19
> --- nodes-table.c 2001/04/03 02:16:10 1.18
> +++ nodes-table.c 2001/04/05 19:16:37 1.19
> @@ -522,7 +522,6 @@
> SVN_ERR (DB_WRAP (fs, "checking for next node branch",
> last_key_before (fs->nodes, db_txn,
> svn_fs__id_to_dbt (&key, new_id, pool))));
> - svn_fs__track_dbt (&key, pool);
>
> {
> svn_fs_id_t *last_branch_id = svn_fs_parse_id (key.data, key.size, pool);
>
>
>
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:28 2006