Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334744

Summary:	Contract of CDOConflictResolver2 not met
Product:	[Modeling] EMF	Reporter:	Caspar D. <caspar_d>
Component:	cdo.core	Assignee:	Eike Stepper <stepper>
Status:	CLOSED FIXED	QA Contact:	Eike Stepper <stepper>
Severity:	normal
Priority:	P3	CC:	pascal.lehmann, saulius.tvarijonas, stepper
Version:	4.2
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Caspar D.

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

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

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.

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

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

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

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

2012-10-31 14:07:52 EDT

I'm going to update the docs...

Comment 8 Eike Stepper

2012-10-31 14:08:21 EDT

commit 0353264ea89db94222190f83d048bb38153bdd27

Comment 9 Eike Stepper

2013-06-27 03:30:26 EDT

Available in R20130613-1157 (4.2)