monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] segmentation fault in changesetify


From: Martin Kihlgren
Subject: Re: [Monotone-devel] segmentation fault in changesetify
Date: Wed, 6 Apr 2005 08:28:51 +0200
User-agent: Mutt/1.5.6+20040907i

On Tue, Apr 05, 2005 at 07:29:28PM -0700, Nathaniel Smith wrote:
> On Tue, Apr 05, 2005 at 09:18:52AM +0200, Martin Kihlgren wrote:
[snip]
> Ah, well, then I'll go with the easiest solution.  Using your 0.17
> monotone, on the post-migration database, try running:
>   $ monotone --db=foo.db db execute "delete from manifest_certs where id = 
> '5954cc14d6096749b9112cf59cce0b6ef304efe8' and name = 'ancestor'"
>   $ monotone --db=foo.db db execute "delete from manifest_certs where id = 
> 'b7ba8f46ddcbd46b71127564469bdbb10bf8323f' and name = 'ancestor'"
> 
> This _should_ allow your changesetify to run, and leave you with a
> working history.

It worked! Thanks a bunch!

> It will break both loops, and leave you with graphs looking like
> 
>   A
>   |
>   B  C
>   | /
>   D
>   |
>   E
> 
> which may be a little mysterious; I'd suggest after you finish the
> migration you use monotone-viz or similar to find the new revision ids
> corresponding to the "C" node above (there will be two of them), and
> using 'monotone comment' to attach some explanation of what happened,
> so as not to confuse yourself when browsing history at some point in
> the future...

I will do that, thanks for the hint :)

> > 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 :)
> 
> This would indeed be elegant, but very difficult -- impossible in the
> general case -- and generally not worth it for a command that you may
> be the last person to ever run :-).  (Or if there are still other
> pre-0.14 users holding out out there, at least there are only a small,
> finite number of times this command remains to be run...)

True, true.

Thank you very much for your help!

regards,
//Martin Kihlgren

-- 
###################################################################
It is much easier to suggest solutions when you know nothing about the problem.
###################################################################



reply via email to

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