Re: [Monotone-devel] how to recover damaged database?
On Sun, 2006-05-07 at 17:11 -0500, Kelly F. Hickel wrote:
While testing the import of our CVS repo, the machine was rebooted.
After the reboot, when I tried to continue importing, I received the
message below. In this instance, I could just start over, but it
raises the question of what would happen if we were using this for
real? We’d have a daily backup of course, but if this turned out to be
unrecoverable, that would be “bad” (I realize that I have no reason to
believe it’s unrecoverable, just wondering)….
In general every developer will have a full copy of the repository,
up-to-date as of the last time they synced. So if any copy get an error
in it, you can just delete it and have everyone sync again. You can only
lose data this way if the database that goes bad is a developer's
database, and they've committed changes but not synced with anyone else
yet. If the server database goes bad, there won't be any data loss.
Original message:
[EMAIL PROTECTED] mtn_repo]$ mtn --db=imported.mtn
--branch=com.mqsoftware.qpasa cvs_import /usr/cvsroot/master/qa
mtn: branches | versions
mtn: 45 |1,225 amqsput_coa/amqsput.c,v
mtn: branches | revisions | versions
mtn: 45 |72 |1,225
mtn: fatal: std::logic_error: revision.cc:50: invariant
'I(null_id(edge_old_revision(i)))' violated
That code is:
void revision_set::check_sane() const
{
// null id in current manifest only permitted if previous
// state was null and no changes
if (null_id(new_manifest))
{
for (edge_map::const_iterator i = edges.begin();
i != edges.end(); ++i)
I(null_id(edge_old_revision(i)));
}
...
The code says, The manifest can only be null if all parent revisions
have a null id; ie, if this revision doesn't have any parents.. I don't
think this matches the comment?
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] how to recover damaged database?
On Sun, 2006-05-07 at 22:49 -0500, Timothy Brownawell wrote:
void revision_set::check_sane() const
{
// null id in current manifest only permitted if previous
// state was null and no changes
if (null_id(new_manifest))
{
for (edge_map::const_iterator i = edges.begin();
i != edges.end(); ++i)
I(null_id(edge_old_revision(i)));
}
...
The code says, The manifest can only be null if all parent revisions
have a null id; ie, if this revision doesn't have any parents.. I don't
think this matches the comment?
Here's an easy way to trigger that invariant:
$ mtn -d test.mtn db init
$ mtn -d test.mtn -b test setup .
$ touch foo
$ mtn add foo
mtn: adding foo to workspace manifest
$ mtn ci -m foo
mtn: beginning commit on branch 'test'
mtn: committed revision 166d10fed2842b0a39b0710c2b0f2e886d34fda0
$ mtn drop -R .
mtn: dropping foo from workspace manifest
mtn: dropping from workspace manifest
$ mtn ci -m boom
mtn: fatal: std::logic_error: ../revision.cc:50: invariant
'I(null_id(edge_old_revision(i)))' violated
mtn:
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the output of 'mtn --full-version',
mtn: and a description of what you were doing to
[EMAIL PROTECTED]
mtn: wrote debugging log to /home/tbrownaw/src/test/_MTN/debug
mtn: if reporting a bug, please include this file
I think this is a very silly requirement to have. First of all, if we
allow the tree to have a null manifest (either only in the initial
revision, or any time until we put something in it, depending on whether
you go by the code or the comment), why do we not allow it to go back to
having a null manifest?
msh has pointed out[1] that a null manifest indicates that the roster
doesn't have a root node, and that we have I(has_root()) is
roster_t::check_sane() . So why do we ever allow a null manifest at all?
OTOH, it's possible to drop everything and then replace it with new
files (add a new dir, pivot_root to that dir, drop your old root dir)
even without drop -R . (which should be made illegal if we keep these
checks), so why shouldn't it be possible to split this into two commits?
[1]
http://colabti.de/irclogger/irclogger_log/monotone?date=2006-05-08,Monsel=15#l23
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
