svn: database disk image is malformed
Rainer Dorsch
I see here a strange behavior of subversion:
I have a local modification:
$ svn diff
Index: README
===================================================================
--- README (revision 929)
+++ README (working copy)
@@ -10,3 +10,4 @@
Contains project administration documents for the project like the project
plan
- att
att traces
+
$
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.
$ svn diff
Index: README
===================================================================
--- README (revision 929)
+++ README (working copy)
@@ -10,3 +10,4 @@
Contains project administration documents for the project like the project
plan
- att
att traces
+
$
But the repository has the change(!), and I can update
$ svn update
G README
Updated to revision 930.
$
Then my local diff is gone
$ svn diff
$
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?
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
jabber: rdo...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
Stefan Sperling
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. 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.
Stefan
Daniel Shahaf
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;
@@ -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
Daniel Shahaf
Committed the first hunk in r1051559; the second hunk is IMO unnecessary
once http://mid.gmane.org/4D0FAB1A...@orcaware.com is addressed.