Daniel Shahaf wrote on Sat, Dec 18, 2010 at 20:41:43 +0200:
> CC += dev@
>
> Stefan Sperling wrote on Thu, Dec 16, 2010 at 18:49:22 +0100:
> > On Thu, Dec 16, 2010 at 05:03:00PM +0100, Rainer Dorsch wrote:
> > > I try to commit the change
> > >
> > > $ svn commit -m "minor change"
> > > Sending README
> > > Transmitting file data .svn: Commit failed (details follow):
> > > svn: database disk image is malformed
> > > svn: database disk image is malformed
> > > $
> > >
> > > And get an error back.
> ...
> > > I found several posts discussing the
> > >
> > > svn: database disk image is malformed
> > >
> > > issue. The best solution is saw is to dump the repository and create a
> > > new one
> > > from the dump.
> > >
> > > Is there an easier way to fix the problem in a robust manner? Does maybe
> > > even
> > > svn provide some fix scripts?
> >
> > This error message is coming from sqlite, not from Subversion.
> > You probably have a broken sqlite database in the repository.
> >
> > The only place I can think of where sqlite is used in FSFS is
> > the rep-cache.db file.
>
> [ For future archeologists, format-5 fsfs repositories (which will
> created by Subversion 1.7) will also use sqlite for the revprops.db
> file. ]
>
> > Have you got rep-sharing enabled on the repository?
> > See the file repos/db/fsfs.conf.
> >
> > You can safely disable rep-sharing. Maybe this will get rid of the error.
> > If it does, try to recover the rep-sharing.db using sqlite (though I
> > don't know how you could do that). If you cannot recover rep-cache.db,
> > move it out of the way and Subversion will create a new rep-cache.db
> > sqlite database. But it will be empty.
> >
> > Representation sharing is not required for a commit to succeed.
> > This would explain why you see a successful commit in spite of the error.
> >
>
> How about the second hunk of this patch then?
>
> I haven't compiled it, and it abuses error codes (to use the
> specific error code that clients recognize), but is the idea sound?
>
> [[[
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===================================================================
> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1044834)
> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
> @@ -5426,9 +5426,20 @@ rep_write_contents_close(void *baton)
> /* Check and see if we already have a representation somewhere that's
> identical to the one we just wrote out. */
> if (ffd->rep_sharing_allowed)
> - /* ### TODO: ignore errors opening the DB (issue #3506) * */
> - SVN_ERR(svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> - b->parent_pool));
> + {
> + svn_error_t *err;
> + err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> + b->parent_pool);
> + if (err)
> + {
> + /* Something's wrong with the rep-sharing index. We can continue
> + without rep-sharing, but warn.
> + */
> + (fs->warning)(fs->warning_baton, err);
> + svn_error_clear(err);
> + old_rep = NULL;
> + }
> + }
> else
> old_rep = NULL;
>
Committed the first hunk in r1051559; the second hunk is IMO unnecessary
once http://mid.gmane.org/4d0fab1a.3060...@orcaware.com is addressed.
> @@ -6377,12 +6388,22 @@ svn_fs_fs__commit(svn_revnum_t *new_rev_p,
> SVN_ERR(svn_fs_fs__with_write_lock(fs, commit_body, &cb, pool));
>
> if (ffd->rep_sharing_allowed)
> {
> - /* ### TODO: ignore errors opening the DB (issue #3506) * */
> - SVN_ERR(svn_fs_fs__open_rep_cache(fs, pool));
> - SVN_ERR(svn_sqlite__with_transaction(ffd->rep_cache_db,
> + svn_error_t *err = SVN_NO_ERROR;
> +
> + if (! err)
> + err = svn_fs_fs__open_rep_cache(fs, pool);
> +
> + if (! err)
> + err = svn_sqlite__with_transaction(ffd->rep_cache_db,
> commit_sqlite_txn_callback,
> - &cb, pool));
> + &cb, pool);
> +
> + if (err)
> + /* The opposite of svn_error_quick_wrap(): same error message,
> + different error code. */
> + return svn_error_create(SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED, err,
> + /* TODO: svn_error_best_message() */
> (err)->message);
> }
>
> return SVN_NO_ERROR;
> ]]]
>
> > Stefan
