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,Mon&sel=15#l23 Tim _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel