| Re: [egit-dev] Logical model support for merge operations |
|
Hi, I can't really answer that without writing a wall of text so... please bear with me :p. You can try this with
either the "sample" model provider and merger I have defined in
these unit tests (1), or with the more advanced one we have in EMF
Compare (2).
(1) This model provider is defined so that all files with the "sample" extension located in a single folder will be considered to be part of the same logical model, and must thus be compared, replaced, merged, ... together. This doesn't amount to much since they are simple text files with no real connection between them but that's sufficient for the tests I currently have. We could assume that these files have a very strict parser and that they thus cannot be impaired with the "textual" conflict markers (>>>> ==== <<<<) much like MANIFEST.MF files do, but that'll come later. For now, the SampleResourceMappingMerger I've defined to merge them only delegates to the default Team one, which has pretty good results on textual files, and which takes responsibility for deleting files when needed. Manually testing that we pass through this merger can be done by reenacting the test case I've defined as a unit test :
Now, without the patchs applied, the merge will end in conflict as it will go through the default git merger. With the patchs, the merge will properly see that as an automatically mergeable conflict : even though these are "model" mergers, a "model" can be comprised of a single file. This is a way for resource format provider to better tell Team how the merges should be handled. It wouldn't have been the same if we had appended content at the start of the file in step 9, as that would have been a conflict either way. You can try out multiple use cases, the one that causes a failure in the auto-staging hook for deletions is if we change step 7 to "delete the test file" and do nothing in step 9 and 10 : just delete the file in a branch, checkout master then try and merge : an exception will make the operation as a whole fail. Do note that these changes do not honor the "allow models to participate in synchronization" preference yet... or a preference to disable models during merge if we'd rather introduce another one. (2) This model provider is defined to use EMF Compare for the EMF files (I'll always use "EMF files" here to avoid confusion : they are usually named "models" but these are not the same models we are talking about here) instead of comparing them textually. Indeed, these are XMI files, with a whole world of tooling to handle them, from loading to validation, with their own editors to avoid manually twiddling with the xmi serialization. This also means that adding "foreign" information inside of said serialization will break the whole tooling (how would you load an xmi file where the xmi is malformed, or "corrupted" by, say, the git conflict markers?). Furthermore, some things that are detected as conflicts textually might very well be automatically mergeable when handling logically (as in "the EMF way"). We have a set of unit tests aiming in particular at covering the git integration in https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.ide.ui.tests.git . Namely, "GitLogicalMergeTest" (https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.ide.ui.tests.git/src/org/eclipse/emf/compare/ide/ui/tests/unit/GitLogicalMergeTest.java) executes a number of unit tests by launching both of the merge : first text, then logical, asserting the differences between the two and the expected results of both (since 'logical' merge is supposed to have much better results in all cases). You can try this manually. We don't have a working psf or oomph setup, but here is the dependencies you need to install (from a "vanilla" luna). I'd attach a target platform... but that would lack the possibility to launch a new runtime...
Clone both JGit, EGit and EMF Compare (git://git.eclipse.org/gitroot/emfcompare/org.eclipse.emf.compare.git). You don't need me to tell you what you need from JGit and EGit, but here's what I retrieved in my workspace :
From there, apply the patchs you need on the egit repo (jgit
already has what's needed) and you'll be able to test out the
support in a new runtime. I won't go into details about how to
create EMF files, but here's an example that presents
cross-resources links that would be broken by the default git
merge handling :
In the current state of this repository, we have a logical
conflict : in a branch we have deleted a type, while on the
other, master, we have created a new reference to this class.
However, there are no "text" conflict in there since the changes
impact distinct lines. In short, a textual merge will simply
merge the text in both files, making it so that this "new
reference to ClassB" we've created in step 19 is merged in
main.ecore, even though the ClassB in question is deleted as a
result of the successful textual merging of what we did in step
15. The reverse (textual conflict but no logical conflict) can also
happen, with the adverse effect of adding the conflict markers,
preventing the EMF editor from properly parsing the xmi file.
This can also be observed if you change step 18 and 19 to
"rename ClassB into ClassD" : ClassA still references this
class, but we also renamed it while it was deleted in the
branch. This will cause a logical conflict as well as a textual
conflict. I'll stop here, many variations of these cases can be done, but
as you can see even though it is pretty easy, it will be quite
costly to create the environment to test this manually (hence
the unit tests we're creating in EMF Compare, and which I've
started to implement for git itself). Laurent
|
begin:vcard fn:Laurent Goubet n:Goubet;Laurent org:<a href="http://www.obeo.fr";>Obeo</a> email;internet:laurent.goubet@xxxxxxx url:http://www.obeo.fr version:2.1 end:vcard