Bugzilla – Full Text Bug Listing
| Summary: | Additional features not shown by CVS compare | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMFCompare | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | EMF Compare <emf.compare-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | laurent.goubet | ||||
| Version: | 1.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The match, diff and merge process have seen a great deal of improvement in the past week, with the addition of unit tests for most of the different use cases (one use case = one possible "diff" between models) we could think of. There are other use cases that we do not yet detect properly, but your example should already work way better with the latest builds. The use cases that are yet to be unit tested are the multi-valued reference changes. We do detect them, but their detection and merge have not been improved specifically by this latest bunch of unit tests (about 4000 unit tests when we consider all potential combinations). These changes have been pushed on both master and the 1.2 maintenance stream. They are available in the builds - 1.2 integration : I201108090404 - 1.3 integration : I201108090415 If you wish to know which differences we are confident in, and which we are not, you can take a look at the "already tested" list : https://github.com/eclipse/emf.compare/blob/master/plugins/org.eclipse.emf.compare.tests/src/org/eclipse/emf/compare/tests/merge/data/USE_CASES.textile . Leaving the bug opened till we have completed this list. I wanted to test this use case against with EMF Compare 2, though I cannot determine which version of OCL.ecore was "1.9" with EGit (I wish they left viewcvs running). Comparing the version attached here with a number of others gave comparison results that seemed meaningful. Using Team > History on a model an comparing from there does some strange things though (does not seem like we manage to match anything, might be due to our integration with EGit). I had to checkout the different versions of OCL.ecore to compare locally. Closing the bug : - EMF Compare 1.3 had greatly improved the comparison results - EMF Compare 2.1 seems to have a meaningful behavior with this use case |
Created attachment 172846 [details] Example of problem The attached file when synchronized against /org.eclipse.ocl/model/OCL.ecore 1.9 shows no differences, when there are plenty. Compare with latest from head is better, but the differences only appear in the lower pane after tree nodes are expanded.