[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] segmentation fault in changesetify
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] segmentation fault in changesetify |
Date: |
Tue, 5 Apr 2005 00:02:24 -0700 |
User-agent: |
Mutt/1.5.8i |
On Sun, Apr 03, 2005 at 09:16:29PM +0200, Martin Kihlgren wrote:
> - I have put the original (0.14) database at
> http://troja.ath.cx/~zond/files/monotone.db-pre-change
> - I have put the new (the one I have dumped, loaded etc - that the "db
> changesetify" failed on) database at
> http://troja.ath.cx/~zond/files/monotone.db
Ah-hah, this helps (and the backtrace confirms it) -- the problem is
that you have a loop in your ancestry. (This was possible back in
0.14, and one of the reasons changesets were created...) The rebuild
code traverses the graph it's rebuilding recursively, and we forgot to
put in a cycle-detector. So... it ends up trying to find the end up
the loop, goes around a few thousand times, and eventually runs out of
stack space. Oops.
It's not possible to express something like this in modern monotone,
which is normally good ;-), but in your case it's a little bit bad,
because it means that there's no way to directly translate your
history.
The exact problem is that you have two loops:
6d4e39 -> be6472 -> 5954cc -> be6472
f026d7 -> 6dcfe8 -> b7ba8f -> 6dcfe8
^^^^^^ ^^^^^^ <-- these are the same
^^^^^^ <-- this is the problematic node
I would guess that what happened is that you made some change, and
then decided it was a bad idea after all and reverted it, returning
you to the previous tree state.
So... we have to untangle this somehow. There are a few choices:
- kill the problematic manifest entirely. This removes it (and it
alone) from your history, which is generally considered a bad
thing, but perhaps you don't care in this case. This requires
some playing around with the database, so as not to break the
delta encoding stuff, but I can do it.
- kill one of the edges. this would leave you with a somewhat odd
looking revision graph, like:
A A
| |
B C or B
| / |
D D
| | \
E E C
depending on which edge we kill. Either should work fine, though
in the latter case you'd have a little merging to do, and you
could still see every historical version (albeit in a strange
setup). This is extremely easy to do; it would only require
removing one cert from the database.
- actually unravel things the way they would be if you'd been using
revisions all along. This is the most correct thing to do, but
also the trickiest; the easiest way is probably to write some
special one-use-only code to revision.cc that would look at the
graph it had constructed, check for the (hardcoded) manifest ids
mentioned above, and tweak the graph appropriate in a hardcoded
way. Not too hard if you only need it to work once :-). But
tricky to check what your thoughts were before going ahead and
doing it.
-- Nathaniel
--
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."