monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Break after kill_rev_locally


From: Ludovic Brenta
Subject: Re: [Monotone-devel] Break after kill_rev_locally
Date: Mon, 08 Oct 2007 20:44:46 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"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.

-- 
Ludovic Brenta.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]