Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 334744 - Contract of CDOConflictResolver2 not met
Summary: Contract of CDOConflictResolver2 not met
Status: CLOSED FIXED
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 4.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eike Stepper CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-19 04:31 EST by Caspar D. CLA
Modified: 2013-06-27 03:30 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Caspar D. CLA 2011-01-19 04:31:24 EST 
The JavaDocs for CDOConflictResolver2 specify the following
for the map passed into the resolveConflicts method:

"Each value in this map is a Pair that optionally contains
the old remote revision (ancestor) as element1 and
the remote delta as element2."

But the logic that constructs these pairs, i.e.
AbstractCDOView.invalidate(*), lines 1188-9 in HEAD, clearly
take the revision from the *local* object.

Do we need to fix the docs, or the code?
Comment 1 Pascal Lehmann CLA 2011-01-25 04:17:54 EST 
I don't remember exactly what we discussed when introducing the new interface, but I think the idea of passing the ancestor is based on how branch merging works.
I quickly checked the CDO provided ConlictResolver implementations and couldn't find one actually making use of the passed 'oldRevision'. So I don't see a problem changing the code (if we can get an ancestor in all cases..), but we might break client code which already relies on the revision which is currently passed (though, the revision could always be fetched from the conflict object itself), so updating the javaDoc might be better.
Any more thoughts, Eike?
Comment 2 Eike Stepper CLA 2011-01-25 06:09:24 EST 
Now that I've deprecated AbstractObjectConflictResolver I wonder if we can deprecated or remove CDOConflictResolver2 altogether?

The new CDOMergingConflictResolver doesn't need it...
Comment 3 Caspar D. CLA 2011-02-08 02:34:30 EST 
(In reply to comment #2)
> Now that I've deprecated AbstractObjectConflictResolver 

I see no annotation to that effect in the source file...
Comment 4 Eike Stepper CLA 2011-02-10 02:40:52 EST 
I've removed it again because CDOMergingConflictResolver is not yet stable. In addition Martin and I realized that a merger can not produce exactly the same result in terms of possible local modifications.
Comment 5 Eike Stepper CLA 2012-06-05 07:28:44 EDT 
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems.

Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Comment 6 Eike Stepper CLA 2012-08-14 22:50:41 EDT 
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 7 Eike Stepper CLA 2012-10-31 14:07:52 EDT 
I'm going to update the docs...
Comment 8 Eike Stepper CLA 2012-10-31 14:08:21 EDT 
commit 0353264ea89db94222190f83d048bb38153bdd27
Comment 9 Eike Stepper CLA 2013-06-27 03:30:26 EDT 
Available in R20130613-1157 (4.2)