Re: [Monotone-devel] Break after kill_rev_locally

[Justin Patrin]

On 10/8/07, Ludovic Brenta <address@hidden> wrote:
> "Ralf S. Engelschall" <address@hidden> writes:
>
> > I today had to use "mtn db kill_rev_locally <rev>" where <rev> was the
> > head of a branch. First, everything looked just fine. I freshly checked
> > out a new workspace (now based on the previous revision on the branch
> > which is now the new head), performed a "mtn log" to be sure that just
> > the previous head revision got dropped, etc. Then I edited the sources
> > and tried to commit the changes: Bang!
> >
> > | $ mtn ci -m "adjust key modify commands"
> > | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys'
> > | terminate called after throwing an instance of 'std::logic_error'
> > | what():  lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated
> > | mtn: fatal signal: Abort trap: 6
> > | this is almost certainly a bug in monotone.
> > | please send this error message, the output of 'mtn --full-version',
> > | and a description of what you were doing to address@hidden
> > | do not send a core dump, but if you have one,
> > | please preserve it in case we ask you for information from it.
> >
> > The only way to rescue the situation was to restore the database from
> > the last UFS snapshot (luckily no other changes happended in the
> > meantime) in order to be able to proceed again.
> >
> > For me this looks like "mtn db kill_rev_locally <rev>" does not remove
> > _all_ related information of <rev> and that some remaining/dangling
> > information causes the subsequent commit to break. Hmm...
> >
> > Unfortunately, I was not able to repeat this with a simple test where I
> > created a fresh database, performed three commits and killed the third
> > commit.... :-(
>
> I had the same, or a very similar symptom after killing the head of a
> branch that happened to be a propagate (A to B) node.  I then did "mtn
> propagate B A" (which was what I really intended) and got an
> exception.  The killed revision and the new revision had the same
> revision ID.
>
> To correct the problem, I "sync"ed the offending database into a fresh
> one and could then proceed with the propagate and commit.
>

Yep, kill_rev_locally only partially deletes the revision so if you
end up trying to commit the same revision id again (or possibly other
things) then you get an error. Re-syncing to a new DB should fix it.

-- 
Justin Patrin