Re: [Monotone-devel] monotone merge error

[Thomas Keller]

Am 05.05.10 09:13, schrieb Stephen Leake:
> Stephen Leake <address@hidden> writes:
> 
>> Stephen Leake <address@hidden> writes:
>>
>>> Mando Rodriguez <address@hidden> writes:
>>>
>>>> When attempting to perform a merge we get this :
>>>>
>>>> /
>>>> mtn: 2 heads on branch '0'
>>>> mtn: merge 1 / 1:
>>>> mtn: calculating best pair of heads to merge next
>>>> mtn: [left]  1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598
>>>> mtn: [right] 96c815a1768eb25e49bf74ba3d6e6236adefb30a
>>>> mtn: fatal: error: roster.cc:1826:
>>>> I(left_uncommon_ancestors.find(left_rid) !=
>>>> left_uncommon_ancestors.end())
>>>> mtn: this is almost certainly a bug in monotone.
>>>
>>> I may have time to look at it this weekend.
>>
>> I finally started looking into this.
>>
>> The immediate cause of the crash is an invariant failure in
>> roster.cc:2066 make_roster_for_merge:
>>
>>  I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end());
>>
>> I rearranged the MM and I lines there so left_uncommon_ancestors would
>> be dumped on --debug, and it is empty.
>>
>> ...
> 
> I've made some more progress. The database is inconsistent; the table
> "branch_leaves" has incorrect entries. I can't reproduce the error, but
> the fix is simple; run database::recalc_branch_leaves.

As far as I remember this table is quite new and was added by Tim last
November to speed up certain things - maybe it would be a good idea if
he could have a look into the issue as well...?

> I added 'mtn db recalc_branch_heads' (not committed), and after running
> it, 'mtn heads' correctly shows just one head.
> 
> We could add a check for this to 'mtn db check'; it could compute the
> branch leaves and compare to the current values in the branch_leaves table.
> 
> If no one objects, I'll check in the 'db recalc_branch_heads' command,
> and work on a new check in 'db check'.

The check is definitely a good idea - if we want a separate
recalc_branch_heads command is questionable - for two reasons:

1) I fear we fix something whose original cause we still haven't
understood - as you correctly stated in one of your previous mails
"Before we discuss committing that change, we need to understand why mtn
thinks this graph has two heads, and how it got that way."

2) If we cannot track the problem down and find any other way than
regenerating the branch leave cache to fix the problem, then I'd propose
we call recalc_branch_leaves as part of the `db regenerate_caches`
command (if it doesn't take so long to additionally recalculate them).

Thanks a lot for your findings so far!

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature