Re: [Monotone-devel] segmentation fault in changesetify

[Martin Kihlgren]

Great that it explained the problem :)

Well, if you are willing to solve my problem, feel free to do it any
way you like - all code in my database is currently quite stable, and
I dont foresee any need to find any certain older revision other than
for historic reasons...

I would think the most elegant solution, though perhaps not that easy
to fix, would be to patch the changesetify so that it solves this
problem in one of the ways you mention below - but since this is
perhaps a quite unusual problem and that solution does sound slightly
complicated, I dont actually expect that to happen :)

regards,
//Martin Kihlgren

On Tue, Apr 05, 2005 at 12:02:24AM -0700, Nathaniel Smith wrote:
> 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."
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

-- 
###################################################################
May's Law:
        The quality of correlation is inversly proportional to the density
        of control.  (The fewer the data points, the smoother the curves.)
###################################################################

signature.asc
Description: Digital signature