On 10/8/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: > "Ralf S. Engelschall" <[EMAIL PROTECTED]> 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 [email protected] > > | 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
