[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Monotone bug, maybe workaround
From: |
Justin Patrin |
Subject: |
Re: [Monotone-devel] Monotone bug, maybe workaround |
Date: |
Tue, 19 Jul 2005 16:00:49 -0700 |
On 7/19/05, Leif Jakob <address@hidden> wrote:
> On Tue, Jul 19, 2005 at 09:52:20AM -0700 Justin Patrin wrote:
>
> > Date: Tue, Jul 19, 2005 at 09:52:20AM -0700
> > From: Justin Patrin <address@hidden>
> > To: To address@hidden
> > Subject: [Monotone-devel] Monotone bug
>
> Hi Justin,
>
> > monotone: fatal: std::logic_error: revision.cc:185: invariant
> > 'I(*changesets.find(old_id)->second == *old_to_child_changes_p)'
> > violated
>
> Guess I've bounced into this bug multiple times as well.... But I
> could't provide a database because of closed source... maybe your
> database would help?
If I can get it back into that state I'll strip my key and send it on.
It's >50MB, though.
Actually what I did was to go back through the merge and not eall of
the manual merges. Then I made all of the manual merge changes to my
checked out copy, checked in those changes, and re-ran the merge. The
merge worked this time. As I said, I'll see if I can put it back into
the broken state and see if the below works.
>
> If you look at the output of your "monotone merge" you will see a parent
> revision that was the root of the revision tree (use monotone-viz) and
> that merge crashes because of plenty of adds/removes (dont't know why)...
>
> But I've a workaround:
>
> run "monotone heads" and see the two (hex) revisions, then run
> "monotone lca $rev1 $rev2" and get the common acestor, now run
> "monotone explicit_merge $rev1 $rev2 $ancestor $branch" and
> it magically should work...
>
> The "monotone merge" uses some "other" ancestor-algoritm, but that
> seems to degrade sometimes...
>
> To be on the safe side make a backup of the database.
>
> Have fun
>
> Leif
>
--
Justin Patrin