[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] conflict messages
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] conflict messages |
Date: |
Tue, 11 Dec 2007 21:49:08 -0700 |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071116) |
Nathaniel Smith wrote:
> On Mon, Dec 10, 2007 at 09:02:54PM -0700, Derek Scherger wrote:
>> I really don't expect that this change is going to cause any major
>> problems but a few "fetching non-existent entry from children" type of
>> errors would not really surprise me. There are a lot of node ids being
>> looked up in several different rosters and while I tried hard to be
>> thorough it's very possible that I've missed something.
>
> Maybe you could test it? :-)
There is a reasonably comprehensive test in tests/conflict_messages at
the moment that generates each of the various conflict types and runs
update, show_conflicts, merge, pluck and merge_into_workspace against
them to ensure these all report things correctly. You do make me realize
that it doesn't yet run explicit_merge or propagate on each of these
cases and doing so should be simple enough so I'll add that.
> (Depending on what interface it uses, you may just be able to plug it
> into the giant merge unit tests -- they should be creating every
> possible conflict situation.)
At a glance it doesn't look like it will fit nicely into the existing
merge unit tests. None of these set up a parent roster which is used
various places to get old names and such. Access to the parent roster
comes from the get_ancestral_roster functions in
content_merge_workspace_adaptor and content_merge_database_adaptor and
we would need to set the tests up with some other
content_merge_testing_adaptor. To some degree it seems like we'd be
testing the test code rather than the real code and we would still be
missing variations of the various merge commands.
Looking at the unit tests I think I have all of the
simple_structural_conflicts cases covered in the existing lua test and
maybe I'll just try and add the complex_structural_conflicts cases to that.
Even with this it still won't surprise me if we hit a "fetching
non-existent node from children" problem or two. ;)
Cheers,
Derek