Re: [Monotone-devel] how to recover damaged database?

[Timothy Brownawell]

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
address@hidden
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,Mon&sel=15#l23


Tim