How to version Ecore files

Integrating the EMF Store to the JDT workbench.
This post summarizes our talk at the Eclipse Summit. Thanks to Adrian for wrapping things up…
Source code is managed by repositories such as CVS, SVN, GIT or others. Many projects store their EMF models, namely Ecore files in the same repository. This involves problems in handling conflicts and merges. The EMFStore is designed to version EMF model instances related objects. As Ecores are also model instances, the EMFStore is also able to version them.
At the Eclipse Summit we presented an integration of the EMFStore into the JDT workspace. The aim of the EMF Store JDT integration is that it gives developers the possibility to manage Ecores not only by the current repository, but in addition by the EMF Store. The integration is unobtrusive in order to keep the development process mainly untouched. This means that the user can use the wellknown actions like commit and update provided by the current used source repository. An EMF Store will lead to an improved conflict handling for EObjects. The EMF Store JDT also deals with the problem that some developers might have the EMF Store JDT installed but others do not. To keep both repositories in synchronization, changes that are done by a user with the EMF Store JDT plug-in will be stored redundant on both repositories.
This post shows various ways how merging issues during collaborative work can be solved and especially how the EMF Store can improve and reduce these merging conflicts.

Use case to demonstrate a usual issue
As an example for a conflict in an Ecore, we will use the default EMF example “library”. Let’s assume this library project is already shared via SVN and the initial state is checked out by user A and user B. The relevant part for this article is visualized in screenshot 1.

Screenshot 1: Library Ecore example

 

 

Now user A changes the attribute “name” of the class “Writer” from “name” to “author”. User B changes at the same time the upper bound of the same attribute from “1” to “2”.
At first user A commits the changes that were done to the project. This commit can be performed without trouble. Now user B wants to commit but user B cannot directly commit. SVN notifies the user about a conflict. This conflict can be now handled via “Text Compare”, “EMF File Compare” or if applied “EMF Store”.

Text Compare
This conflict can be inspected with the action “Synchronize with Repository”. The first comparison that can be used is the “Text Compare”. Screenshot 2 illustrates the differences between the local file and the current remote one. For a human being it is obvious that another user changed the value of the attribute name from “name” to “author”. In addition the local file got an additional attribute “upperBound” with the value “2”.

Screenshot 2: Text Compare

Since a local file is compared with a remote file, changes from the remote file can only be applied to the local one. The local file is shown at the left side and the remote file at the right side. To apply the remote change, that the attribute “name” has been renamed to “author”, the first entry from the list has to be selected. Than the button “Copy Current Change from Right to Left” has to be clicked.

Screenshot 3: Text compare- change applied

The button suggests that the remote change can be integrated to the local one. Unfortunately, the line where the remote difference has been discovered will be complete copied to the local one and the local line will be also kept. This circumstance is visualized in screenshot 3. This means a lot of post processing for the developer to select which changes should be kept in fact.

EMF File Compare
Since in the use case an Ecore file has been changed, an EMF File Compare is also available. The recognized changes are shown in screenshot 4. As the EMF File Compare knows about the structure of an Ecore file, better merging can be achieved. The upper part shows again the “Structural differences” view. This view shows exactly what has been changed. The user may even read that the attribute “name” has been remotely changed to “author”. The second change also displays that the upper bound has been locally changed from “1” to “2”.

Screenshot 4: EMF File Compare

As previously mentioned, this method compares a local file against a remote file. So changes can be only adapted to the local one. To get the change that the attribute name has been renamed to author, the respective change has to be selected and the button “Copy Current Change from Right to Left” has to be pressed. The result of this action is that the renaming will be locally performed and the author attribute has now the cardinality with the upper bound 2. At this point all merging has been successfully done and the commit can be finally performed. The preliminary conclusion is that the EMF File Compare is much more powerful than a simple diff is. But there is still room for improvement.

EMF Store JDT (1)
As the EMF Store JDT is an addition to already shared projects, the current used source repository can be used further on. To use the EMF Store for Ecore files, it is necessary to connect a local file to an EMF Store. To reach this, right click on the desired file and select from the context menu “Push to EMF Store”. A dialog appears where an EMF Store has to be selected. This dialog is displayed in screenshot 5.

Screenshot 5: EMFStore Project Selection

Right after a project has been selected the origin file has got an additional decoration that indicates that the file is under EMF Store control. This state can be seen in screenshot 6 for the file library.ecore. The version in the brackets is the EMF Store project version. This is currently 0, due to the fact, that the project where the library.ecore is stored, has not been committed yet. The following number 10 stands for the SVN revision of the file.

Screenshot 6: Ecore File under EMFStore Version Control

A commit of the library project will effect that other users will see as well that the file has been put under EMF Store control. Let assume user A has made this commit and user B updates the project. Now user A and B make the same changes as in the initial use case described. User A performs a commit as usual. First, the SVN commit dialog will be displayed and the user can enter a commit message. The user can choose which files should be committed. After pressing on OK the SVN commit has been confirmed and the commit dialog of the EMF Store will be displayed. Here the user can verify the changes in detail that will be committed to the EMF Store. The EMF Store commit dialog can be viewed on screenshot 7. User A confirms this by clicking on OK.

Screenshot 7: User A - EMFStore Commit Dialog

Now user B does a commit, too. Again, first, the SVN commit dialog will be shown and then the EMF Store commit dialog. But before the EMF Store commit dialog will be shown a message is shown to the user that the local EMF Store project is outdated as visualized in Screenshot 8. User B confirms the question with “Yes”.

Screenshot 8: EMFStore Project is outdated

 All update changes are shown again in a dialog and the user can inspect if they should be applied to the local project or not. So here the user can recognize that the attribute name has been changed to author. After that the actual commit will be performed. The dialog will look very similar to screenshot 7, but the change operation will be that the “upper bound” of the attribute “author” has been set from “1” to “2” and the commit can be applied safely.
This means the user has not had to accomplish with merging issues. They could be solved autonomously without bothering the user. The user only had to update the local outdated version.
Someone may ask what has been committed to the SVN repository. Internally the EMF Store performs first the commit, it solves the merging conflicts and then the content will be also written back to the local file. This means the conflict is solved for SVN, so SVN committed the modified and conflict free version. So users who do not have the “EMF Store JDT” plug-in installed, will also get the correct version as they will update their project.

EMF Store JDT (2)
As previously seen, the EMF Store can merge situations where currently established tools get into trouble. Obviously, there are situations, where a merge cannot be solved without asking the user which changes should be kept. Such a situation can be caused by the following procedure: User A and user B have the same version checked out. If they do a change on the same object e.g. the same attribute, then it is not possible to decide independently which change should be kept. Let assume user A changes the attribute “name” of the class “Writer” as in the initial use case from “name” to “author”. User B changes also the name attribute from “name” to “writer”. The first commit can be safely applied but for the second one, the user gets a dialog, where the conflict will be shown. Such a conflict is depicted in screenshot 9.

Screenshot 9: EMFStore Merge Wizard

 As visualized in screenshot 9 the user can read the conflict description:
“You have changed the name attribute of EAttribute “writer : EString” to writer. This attribute was changed to author in the repository.”
To solve this issue the user gets the option to easily decide how to solve it. Either one can click on “Keep My Change” or on “Keep Their Change” or an issue can be created.
If multiple merging conflicts exist, several of these sections will be shown. After all merging issues have been decided how to be solved, the decision will be applied and the commit can be finally executed.

Conclusion
The EMF Store JDT gives developers for a specialized kind of development artifacts a powerful tool how to avoid conflicts when working in collaboration with other developers. The only obstacle that has to be taken is that in addition to the already used source repository an EMF Store has to be selected when starting to add an EMF related file under EMF Store control. Since this is needed only once and only for one developer, the configuration overhead is minimal and the whole team can avail the benefits of the EMF Store. The JDT integration is currently under development. We are testing the integration with SVN and are further working on an integration with GIT. We plan to provide a release at the beginning of 2011.  If you are interested in the functionality, feel free to contact us or leave a comment.