Re: [Monotone-devel] Break after kill_rev_locally
Ludovic Brenta schrieb: Ralf S. Engelschall [EMAIL PROTECTED] writes: 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 synced the offending database into a fresh one and could then proceed with the propagate and commit. The problem is already fixed on mainline and goes into 0.37. The roster which is attached to each revision is not removed, thus if you try to commit the same revision again it cannot store the roster (which has then the same revid) again. The fix now just checks if the roster exists before a revision is committed, and if it exists, skips this step. There have been long discussions and explanations why we do not remove the roster on kill_rev_locally, please search the mail archive if interested in the conclusions. Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
Thomas Keller [EMAIL PROTECTED] writes: The problem is already fixed on mainline and goes into 0.37. The roster which is attached to each revision is not removed, thus if you try to commit the same revision again it cannot store the roster (which has then the same revid) again. The fix now just checks if the roster exists before a revision is committed, and if it exists, skips this step. There have been long discussions and explanations why we do not remove the roster on kill_rev_locally, please search the mail archive if interested in the conclusions. Thanks. I approve of not removing the roster and the fix is just fine. BTW, I was not really complaining as the workaround I described (syncing into a fresh database) was rather straightforward. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Break after kill_rev_locally
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 monotone-devel@nongnu.org | 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 :-( Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
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 monotone-devel@nongnu.org | 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 synced the offending database into a fresh one and could then proceed with the propagate and commit. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
