# EMF Compare tutorial

The aim of this tutorial is to guide you through the basic mechanisms of EMF Compare. The first part of this tutorial will explain you how to set up your environment. The second will help you understand the main differences that EMF Compare detects. The third part will explain you how EGit can interoperate with EMF Compare to compare model from a git repository.

## Installation

EMF Compare is part of the Eclipse release train. You will find all you need in the eclipse release update of your platform. You can also find newer version on EMF Compare web site in the download section.

In order to install EMF Compare:

- Open the installation wizard : Help > "Install New Software..".
- Select the update site from which you want to install EMF Compare. In this example we are using the Luna eclipse release update site:
  - http://download.eclipse.org/releases/luna
- Check the feature called "EMF Compare IDE UI".

- Click on next.

- Click on next.
- Read and accept the terms of the license agreement.

- Click on finish.
- Once the installation is finished click on "Yes" to restart your platform.

## Tutorial

### Set up

#### Install custom ExtLibrary plugins

This tutorial is based on the well know ExtLibrary meta-model (available from the EMF examples). However for the needs of this tutorial we have customized those plugins. We have:

- Set up a XMI id serialization to create models in which each element will have a unique id. EMF Compare can compare both models with id and models without id. If no ids are available in the model, EMF Compare uses a heuristic to define if two elements match.
- Removed the extendedLibrary content type to explain you how to set it up in your platform.
- Added extra icons to make it look prettier.

##### Import the plugins

Those plugins are hosted in the EMF Compare repository. To import those plugins in your workspace you can follow the EGit tutorial. Here are the main steps:

- Clone EMF Compare repository using the following URL (see Clone a repository for further information):
  - http://git.eclipse.org/gitroot/emfcompare/org.eclipse.emf.compare.git
- Import the required plugins into your workspace:
  - Open the "Git Repositories" view (if not already opened): Window > "Show view" > "Other...".
  - Select "Git Repositories".
  - Select your clone of EMF Compare repository.
  - Open the contextual menu and click on "Imports Projects..."
  - Select the "tutorial" folder and click on next.
  - Check that the 3 required plugins are checked:
  - Click on Finish.

In the end you should have your workspace looking like this:

##### Launch runtime platform

Now that you get all you need in your workspace, you need to create a runtime platform. A runtime platform is basically a new eclipse platform built upon your current platform with the new plugins of your workspace included. To do so:

- Select one of the plugin in your workspace.
- Click on the play button in the toolbar . If you do not have this button in the toolbar you might need to switch to the Java perspective.
- Select "Eclipse Application" and then click on OK.
- A new eclipse platform should start. This is your runtime platform.

All the following instructions should be done on the runtime platform.

#### Associate EXTLibrary models with EMF Compare Content type

EMF Compare editor is based on the Content types mechanism. Basically, EMF Compare will be used in a comparison if the Content type of the current resource is either one of the following types(or inherits from one of them):

- XMI content type
- Ecore content type
- EMF Compare content type

You can also use the "Content Types" preference page to associate your model files with EMF Compare content type.

This is the first step of this tutorial. To do so:

- Open the preference page : Window > Preferences.
- Select the "Content Types" preference page: General > Content Types.
- Select EMF Compare item.
- Click on the "Add..." button.
- Write the pattern matching all extlibrary files : "*.extlibrary".
- Click on OK.

If you are using the basic EXTLibrary plugins (imported from examples) this step is not mandatory since a content type is already defined and it inherits from the XMI content type. However, those plugins do not generate ids, so we do not recommend you to use them.

### Tutorial

#### Context

If you have correctly followed the previous steps you should have the following environment:

- The custom ExtLibrary meta-model installed in your runtime
- Associated the .extlibrary files with the EMF Compare content type
- Using EMF Compare default preferences

#### Compare with history (2-way comparison)

Now that everything is set up, we are going to go through all the major differences EMF Compare detects and handles. To do so we will create a library model step by step. Each time that we will modify the library we will compare it with a previous version to see how EMF Compare handles each difference.

##### Create a library model

First we need to create our library model. To do so:

- Create a project with the name "TutorialModel" for example.
- Create an extlibrary model:
  - Click on: File > New > Other.
  - Select EXTLibrary Model.
  - Click on next.
  - Set its name to "TutorialModel.extlibrary" for example.
  - Click on next.
  - Select a Library element as root.
  - Click on finish.

Your model is now open.

##### Create a new book

We are now going to fill your library with your first book.

- Select the library element in your opened editor (In this example TutorialModel.extlibrary).
- Open the contextual menu.
- Select "New Child" > "Book".
- Save your model.

###### Compare with previous version

Now that our library contains one book let's compare it with the previous state of our model:

- Select your model file in project explorer (or package explorer) view.
- Open the contextual menu.
- Select "Compare With" > "Local History...".

The history view is now open.

This view will display each state of the file that Eclipse has saved for you. Each time you will save your model a new entry will appear. The item written in bold is the current version of your file. In the first part of this tutorial you will have to compare the current version of your model with its previous version.

To do so, double click on the entry just below the bold entry.

The EMF Compare editor is now open.

This comparison is a 2-way comparison. That is to say the comparison is only between 2 inputs (the current version of your file and the previous version from your local history). You will see in the second part of this tutorial that there is also a 3-way comparison.

Let's have a look at the user interface. The tool bar look like this:

This toolbar appears when you are in accept/reject mode. This mode is activated when at least one of the inputs is not writable. In our example the current version of your file can be modified whereas the previous version of it cannot (since it is provided by the local history). In this mode you can accept or reject a difference. This is obvious, but the only resource that is going to be modified is the current version of your model.

The top of the editor is filled with the "Structure Merge viewer". In it, you will find a structured representation of all differences that EMF Compare has found.

On the bottom of the editor you have a viewer called "Content viewer". This viewer displays the content of your input models. On the left, it displays the content of the current version of your model. On the right it displays the content of the previous version.

To have a full understanding of the user interface please see User Interface Breakdown.

Now let's have a look at the difference:

On this difference you find some pieces of information:

- The "+" overlay icon indicates that the difference is an addition (see Signification of icons associated with differences for further information).
- The suffix enclosed in brackets describes the nature of the difference and the name of feature which has been modified. In this case, the difference is an addition in the feature "Stock" (The modified feature is not "books" since it is a derived feature. It is computed from the "real" feature "Stock").

In this tutorial, you should never save the EMF Compare editor except if it is explicitly asked. For the moment, EMF Compare does not allow undoing an action if the model has been saved. Since we are going to go through every possible action we are going to make a lot of undo operations.

###### Accept a difference

First accept the modification we have just created. To do so:

- Select the difference you want to accept.
  - Click on the difference within the structure merge viewer (top viewer). Double click on it to open the content merge viewer related to this difference.
- Click on the accept icon .

Your editor should look like this:

A new overlay icon has appeared on the difference. It means that the difference has been merged. You can also notice in the content viewer of the current model version that the book isn't framed any more. This also means that the difference has been merged.

###### Reject a difference

Let's try to reject the difference:

- Undo the previous action using the keyboard shortcut (Ctrl+z) or the File menu (Edit > Undo).
- Click on the reject icon .

Your editor should look like this:

The "x" overlay on the difference icon means that it has been rejected. In the content viewer of the current model version the book has disappeared. Indeed, since the modification has been rejected the previous version of this object is used.

##### Set the name of the book

We are now going to set the name of the book we have just created. This will change the value of the attribute "Title" to "Prelude to Foundation".

- Close the compare editor (without saving).
- Open the model editor.
- Set the name of the book to "Prelude to Foundation".
  - Select the book.
  - Display the Properties view: Contextual menu > Show property view.
  - Fill the title field.
- Save.

Now let's compare it with previous version (see previous chapter for explanation Compare with previous version).

On the difference you see the overlay indicating that this difference is a change. This difference is a set on the feature "Title". If you look on the content viewer of the current version, you will see the new value of the feature whereas in the previous version nothing is displayed.

If you accept the difference you will notice the same effect than in the previous chapter (see Accept a difference).

If you reject the difference the name of the book will be unset since it has not been set in the previous version (see Reject a difference).

##### Change the category of the book

We are going to define that this book is a Science Fiction book. This will change the value of the "Category" feature of the book from its default value "Mystery" to "ScienceFiction".

- Close the compare editor (without saving).
- Open the model editor.
- Change the category of the book to ScienceFiction:
  - Select the book.
  - Open the property view.
  - Change the value of the "Category" feature.
- Save.

Now let's compare it with its previous version (see previous chapter for explanation Compare with previous version).

On the content viewer of the current version you see the new value of the feature "Category" whereas in the previous version the default value is displayed.

Accept the difference and you obviously see (see Accept the difference):

Reject the difference to set the "Category" feature to its default value (see Reject a difference).

##### Fill the library with employees

To fill your library we are going to add some employees.

- Close the compare editor (without saving).
- Open the model editor.
- Create an employee and set last name to Chief.
- Create an employee and set last name to Master.
- Create an employee and set last name to Employee.
- Save.

For this step we are not going to compare with the previous version of the model. EXTLibrary stores persons in feature maps. For the moment feature maps are not correctly handled by EMF Compare. Features map comparison will be integrated for the next Eclipse release (Mars in 2015).

##### Set a manager

Let's set the manager of "Employee" to "Chief". This will set the reference "Manager" of "Employee" to "Chief".

- Select the employee "Employee".
- Open the Properties view.
- Make the "Manager" feature point to "Chief".
- Save.

Now let's compare it with its previous version (see previous chapter for explanation Compare with previous version).

You can notice the change in the content viewer. However it is slightly different from the previous comparison. In the content viewer, you now have a new top image.

It means that the current difference is a non containment reference. If you look back to Compare with previous version the content viewer is not the same since the feature involved was a containment reference.

Accept this difference and you will see the same type of result than Accept a difference.

Reject this difference and you will see the same type of result than Reject a difference.

##### Change of manager

Let's say "Employee" has a new job and so he has a new manager. We have to change the feature "Manager" from "Chief" to "Master".

- Close EMF Compare editor (without saving).
- Open the model editor.
- Select the employee "Employee".
- Set the feature "Manager" to "Master".
- Save.
- Compare with previous.

Accept the change to mark the difference as merged. Reject it to reset the manager of "Employee" to "Chief".

##### No more manager

Let's say that "Employee" has reached the top of the command chain. That is to say he has no more manager.

- Close EMF Compare editor (without saving).
- Open the model editor.
- Select the employee "Employee".
- Unset the feature "Manager" of "Employee".
  - Open Properties view.
  - Select "Manager" field.
  - Use the "Restore Default Value" button in the toolbar.

- Save.
- Compare with previous.

The difference is the opposite of set a manager.

- Accept the difference to get:

- Reject the difference to get:

##### Add borrowers

Let's open the gates of your library to the public. We are going to add borrowers to this library.

- Close EMF Compare Editor (without saving).
- Open the model editor.
- Add a new borrower named Will Graham.

For the same reason explained in Fill the library with employees we are not going to compare the model this time.

##### Borrowing a book

We are going to use your newly created borrower by making him borrow "Prelude to foundation".

- Open the model editor.
- Select the borrower "Graham".
- Add "Prelude to Foundation" to the feature "Borrowed" in the Properties view.
- Save.

- Compare with previous.

In this comparison you can notice two differences: and .

EMF Compare displays two differences whereas you have only made one modification in your model. The explanation is within the structure of the EXTlibrary metamodel. If you look at the feature "borrowed" in extlibrary.ecore you will see that the EOpposite field is set to "borrowers : Borrower".

This means that each time you add/remove a book to a borrower EMF will automatically add/remove the borrower to the "borrower" feature of the book (and the other way around). Modifying one feature will modify the other. It explains why EMF Compare sees two differences.

Now you may wonder what happens when you accept one of the differences? EMF Compare will give you a hint on this matter. First notice the consequences preview button . It can either have its icon set to for "Accept preview mode" or for "Reject preview mode".

When the "Accept preview mode" is activated ( ), EMF Compare will help you understand the consequences of accepting the current selected difference. Let's try it.

- Activate the "Accept preview mode" ( ).
- Select "Borrower Graham [borrowers add]" difference.

Notice that the "Book Prelude to Foundation [borrower add]" difference is highlighted in green. This means that accepting the current difference will automatically accept this difference too. Those two differences are linked by an "Equivalence" element meaning that merging one is equivalent to merging the other. You can reproduce the same behavior by selecting the difference "Book Prelude to Foundation [borrower add]" instead of "Borrower Graham [borrowers add]".

- Accept the difference and check the result.

Both differences have been accepted. Now let's try to reject the difference.

- Undo the previous merge (Ctrl+z).
- Switch to the reject preview mode( ).

- Select one difference.
  - Notice that the other difference is also highlighted in green. Since the two differences are "equivalent" both preview modes show the same consequences. You will see later in another use case that each preview mode can show different consequences.
- Reject the difference.

Both differences have been rejected.

##### Create a new library branch

Now that your library is growing, let's create a new branch in your library. This new library will be affiliated to the main entity but will have an independent life.

- Close EMF Compare Editor (without saving).
- Open the model editor.
- Create a new library under your main library.
- Create a new book within the new library called "1984".
- Save.

- Compare with previous.

EMF Compare displays only one difference whereas you have made two modifications. You have created one sub library and one book. There must be a connection between those two differences... Indeed without the library it's impossible to create the book "1984" since it is included in the new library. For clarity purposes EMF Compare only shows one difference and hides the other one.

- Accept the difference.

EMF Compare has accepted both differences. It has created the new library and the new book. On the contrary let's try to reject the difference.

- Undo the previous action (Ctrl+z).
- Reject the difference.

EMF Compare rejects both differences.

In some use cases it can be useful to display both differences. For example if we would like to accept the creation of the library but reject the creation of the book. To do so, you have to use the filter button ( see Filtering Differences for further information).

- Undo the previous action (Ctrl+z).
- Deactivate "Cascading difference" filter.

- Click on "No". It tells EMF Compare not to remember your choice for subsequent comparisons.

Once the filter has been deactivated you will see both differences. Now you can separately merge each difference.

- Activate "Accept preview mode" ( ).
- Select the book difference "Book 1984 [stock add]".

Notice that the library difference is highlighted. Indeed, merging the book difference will necessarily merge the library difference.

- Switch to "Reject preview mode" ( ).

In this mode the other difference is not highlighted. Indeed, you can reject the creation of the book without rejecting the creation of the library. In the same way, selecting the library difference while "Reject preview mode" is activated will highlight the book difference. If the library does not exist then the book can also not exist.

- Activate "Reject preview mode" ( ).
- Select the library difference.

##### Move a book

In order to fill the new library we are going to give it one book from the main library.

- Close EMF Compare editor (without saving).
- Open the model editor.
- Move "Prelude to Foundation" to the new branch library (using drag and drop).
- Save.

- Compare with previous.

With this example we have introduced a new type of change: "moving an element". This means the element already existed in the previous version but was located in a different place. In the content viewer you can see the location of this element in the current and previous versions of your model.

- Accept the change to mark the difference as merged.

- Undo the previous action (Ctrl+z).
- Reject the difference to move back the element to its original location.

##### Remove a book

After an accident the book "1984" has to be removed from the shelves.

- Close EMF Compare editor (without saving).
- Open the model editor.
- Delete the book "1984".
- Save.

- Compare with previous.

This kind of change is the opposite of an addition.

- Accept the change to delete the book.

- Undo the previous action (Ctrl+z).
- Reject the change to add the book back into the library.

#### Compare with repository (3-way)

##### Set up

In this part of the tutorial we will continue building our model. The only difference is that we are going to create different scenarios for each new modification. To do this we need a tool called Git. It is a free and open source distributed version control system. In Eclipse world we are going to talk about JGit and EGit. JGit is a java implementation of Git. EGit is the integration of JGit in Eclipse.

Attention: Remove the book "Prelude to Foundation" from the "Borrowed" feature of borrower "Graham" before continuing. The following examples assume this relation is not set!

###### Create a Git repository

First of all we need a Git repository. You can either use a clone of an existing Git repository or create your own local Git repository. We have chosen the second solution for this tutorial.

- Open the "Git Repositories" view (if not already open): Window > "Show view" > "Other...".
  - Select "Git Repositories".
- Then click on the new repository button .
- Set the location of your new repository. If prompted give it a name.
- Click on finish.

###### Share your model

Now that your repository is ready. Let's put your model in it.

- Select the project holding your model.
- Open the contextual menu: "Team" > "Share project...".
- Select "Git" and click next.
- Choose the repository you previously created and click on finish.

###### Commit your changes

Your project has now been moved into the repository. However your work has not been committed yet. Committing a model is like taking a snapshot of it and saving it for later (see Commiting Changes for further information). To do so:

- Select the project holding your model.
- Open the contextual menu (right click): "Team" > "Commit...".
- Enter a message for this commit describing what has been done. For this example "First commit." will do.
- Select the files you want to commit. In our example select all files.
- Click on the commit button.

Your project has just been committed into your repository. Let's have a look at your repository and its history.

- Select your repository in the "Git Repositories" view.
- Open the "History" view:
  - Open the contextual menu by right clicking on the repository.
  - Choose "Show In" > "History"

It should look like this:

Expand your repository tree in the "Git Repositories" view. In it you can see a folder named "Local" located within "Branches". This folder contains all the branches of your Git repository. In this example each branch will represent a scenario of your model. You can notice that your repository has already a "master" branch. This is your main scenario.

In the history view you can see the graph of all your commits. Currently the only entry available is the first commit you have made earlier. To better understand the changes that we are going to make in the repository, we advice you to click on the "Synchronize" button ( ) and on the "Show all branches" button ( ). This will give you a global point of your repository.

##### Create Scenario 1

Let's create our first scenario. To do so:

- Select the branch within the "Git Repositories" view that will be used as start point your new branch. In this case: master.
- Open the contextual menu: "Create Branch...".

- Set its name to "Scenario1". The button "Checkout new branch" must be checked.

- Click on finish.

You have just created a new scenario that will use the last commit from the master branch as starting point.

###### Change the number of pages

You have now two branches in your repository. Let's modify our model to write our first scenario.

- Open the model editor.
- Select the book "Prelude to Foundation".
- Open the "Properties" view.
- Change the value of the field "Pages" to 374.
- Save.

- Compare this model with the last commit in your repository:
  - Select your model file.
  - Open the contextual menu: "Compare With" > "Head Revision".

This is a comparison between the current version of your model and the snapshot that you have committed earlier. Let's save this version. To do so we are going to commit it. Follow the steps as described in Commit your changes:

- Select the project holding your model.
- Open the contextual menu: Team > "Commit...".

- Enter the commit message: "Set page number to 374".

- Click on commit.

##### Scenario 2: Conflict

Let's create a different scenario. Follow the step described in Create Scenario 1 to create a new scenario called "Scenario2" from the master branch.

- Click on the master branch in the "Git Repositories" view.
- Open the contextual menu: "Create Branch...".
- Set the name of the new branch to "Scenario2".
- Click on finish.

In this scenario we are going to set the number of pages of "Prelude to Foundation" to 375.

- Refresh the model editor by double clicking on the "TutorialModel.extlibrary".
- Set the number of page of "Prelude to Foundation" to 375 (see Change the number of pages for further information)
- Save.
- Commit your changes (see Commit your changes for further information).
- Set the commit message to "Set page number to 375."
- Compare your model with "Scenario1":
  - Select the model file.
  - Open the contextual menu: "Compare with" > "Commit...".
  - Select the commit that holds the "Scenario1" tag.

You should now have an EMF Compare editor open.

The first thing to understand is that this comparison is a 3-way comparison. This means that EMF Compare has used 3 inputs to compute the differences. The first one (in the bottom left) is the local version of your model ("Scenario2"). The second one (in the bottom right) is the version of your model from "Scenario1". And the third one is a common ancestor of the two other versions. The history view gives a picture of the situation.

- Have a look on the history view of your repository.

Both scenario 1 and 2 used the master branch as starting point. This is why it has being used as common ancestor. We will see later on this tutorial how EMF Compare uses this third input. You can display its content in EMF Compare by clicking on the "Show Ancestor Pane" button ( ).

- Let's have a look at the differences.

You can notice a new type of difference: conflicts. Indeed in Scenario1 we set the number of pages to 374 whereas we set it to 375 in Scenario2. EMF Compare is telling us that it cannot be both. If you select one of the difference you will see that the other is highlighted in red. This means that if you merge this difference EMF Compare will not be able to merge the other one.

We are now going to see what will be the impact of accepting or rejecting each difference.

- Select the difference named "375 [page changed]".
- Accept the difference.

In this case EMF Compare has accepted the selected difference and rejected the other one since they cannot be accepted simultaneously. Let's try to reject this difference.

- Undo the previous action (Ctrl+z).
- Switch to "Reject preview mode" ( ).

Notice that nothing is highlighted in red. It seems that rejecting this difference has no consequence on other differences. Let's find out.

- Reject the difference named "375 [page changed]".

In this case EMF Compare only rejected the current difference. When you look at the value of the attribute you will see that the number of page has been set to 100. This value is the value of the same attribute in the common ancestor model (see picture "Common Ancestor 2"). In 3-way comparison you can either accept the version of an attribute from one of the two input version (Scenario 1 or Scenario 2) or return the version to its common ancestor value (master).

Obviously you can do the same actions on the difference named "374 [page changed]". It will:

- Set the value of the attribute to 374 and reject the other difference if you accept it.
- Set the value of the attribute to 100 if you reject it.

Note that after rejecting one scenario you still have to handle the remaining difference. Depending on if you accept or reject it, the final value of the attribute will be the one of the common ancestor or the one of the remaining scenario.

##### Scenario 3: Pseudo conflict

In the previous chapter you have seen how EMF Compare handles two conflicting changes between two scenarios. In this chapter we are going to see how it handles two changes that are semantically the same. Let's create a third scenario:

- Create a new branch named "Scenario3" from the master branch (see Create Scenario 1 to see how to create a new scenario).
- Open the model editor.
- Set the number of pages of "Prelude to Foundation" to 375 (see Scenario 2 for further explanation).
- Save.
- Commit your changes (see Commit your changes). Set the commit message to "Set page number to 375".
- Compare this version with Scenario2 :
  - Select your model file.
  - Open the contextual menu: "Compare with" > "Branch, Tag or Reference...".
  - Select "Scenario2".
  - Click on Compare.

At first glance it seems that no difference was detected. This is not really surprising since the two input models are semantically identical. However you will see that EMF Compare has done some work:

- Deactivate the "Pseudo Conflict" filter.
- Handle the filter popup. Select "Yes" if you want to deactivate the "Pseudo conflict" filter by default for all subsequent comparisons. Select "No" if you prefer deactivating it only for the current comparison. You can also ask EMF Compare to remember your choice by checking the checkbox in the bottom left corner.

Blocked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=435051

EMF Compare has detected two differences. The first difference has been detected between the common ancestor and Scenario2. The second has been detected between the common ancestor and Scenario3. However EMF Compare is clever enough to consider that these two differences are the same.

##### Scenario 4 and 5: Advanced conflict

Now that you have understood how conflicts works we are going to create a more complex conflict. Let's create a conflict between a book that we are going to delete in a scenario (Scenario4) and the same book that we are going to borrow in another scenario (Scenario5).

- Create a new scenario named "Scenario4" from the master branch (see Create Scenario 1 to see how to create a new scenario).
- Delete the book "Prelude to Foundation".
- Save.
- Commit with the message "Deletion of prelude to foundation" (see Commit your changes).
- Create a new scenario "Scenario5" from master (see Create Scenario 1 to see how to create a new scenario).

At this stage of the tutorial your Git repository should look like this.

- Make "Will Graham" borrows "Prelude to foundation".
- Save.
- Commit with the message "Will Graham borrows a book" (see Commit your changes).
- Compare scenario 5 with scenario 4 (see Compare with branch for further information).

If you select each differences you will see that:

- "Book Prelude to foundation[stock delete]" cannot be merged with the two other differences.
  - Accept the difference to get:
  - Reject the difference to get:
      Rejecting it does not automatically accept the other differences. Indeed you can prevent the deletion of the book but still want to choose to accept or reject the other difference.
- "Borrower Graham[borrowers add]" and "Book Prelude to foundation[borrowed add]" are equivalent and they cannot be merged with the third difference.
  - Accept one of them to get:
  - Reject one of them to get:
      The same conclusion goes here. You can reject the setting of the reference and still want to choose what to do with the "delete" difference.

##### Fragment your model

Let's say you want to delegate the work on the sub library to one of your colleagues. To do so you want to give him a file with the sub library and nothing else. Let's extract our new branch library into a new file. In this part of the tutorial we are going to discuss the fragmentation of a model (also called control). The following steps will show you how EMF Compare reacts with models split among several files.

- Create "Scenario6" from the master branch (see Create Scenario 1 to see how to create a new scenario).
- Open the model editor.
- Control the branch library:
  - Select the sub library.
  - Open the contextual menu: "Control...".
  - Set the path of the new target file (Use "Browse Workspace..." button for convenience).
- Save (A new file appears in your project).
- Close the model editor.
- Open the model editor (it needs to be reloaded to see the control decorator).

In your new model you can see that two resources have been loaded (NewLibraryFile.extlibrary and TutorialModel.extlibrary). You can also notice a new overlay icon on the sub library. This means this element is stored in another file (resource).

- Compare with HEAD (see Compare with HEAD).

Eclipse asks you to switch to the "Team Synchronize" perspective, accept.

Blocked https://bugs.eclipse.org/bugs/show_bug.cgi?id=435081

TODO when included in repository - Rebase two branches - Rebase your work on the work of your colleague TODO when included in repository - Merge two branches - Merge your work with that of your colleague