3-Way Project Merge
UModel supports the merging of multiple UModel projects that have been simultaneously edited by different developers, in a 3-way project merge. The 3-way project merge works with top-level UModel projects, i.e. main projects that may contain subprojects, it does not support individual file merging, when these files have unresolved references to other files.
When merging main projects, any editable subprojects are automatically merged as well. There is no need for a separate subproject merging process. For an example, see Example: Manual 3-Way Project Merge. Note the following:
•The whole merge process can be undone step-by-step by clicking the Undo toolbar button, or pressing Ctrl+Z.
•Clicking an entry in the message window displays that element in the Model Tree.
•The file name of the merged file, the first file you opened, is retained.
Merging results
In the following text, "source" means the initial/first project file you open before starting the merge process.
•New modeling elements in the second file i.e. that do not exist in the source, are added to the merged model.
•New modeling elements in the source file i.e. that do not exist in the second file, remain in the merged model.
•Deleted modeling elements from the second file i.e. those that still exist in the source, are removed from the merged model.
•Deleted modeling elements from the source file i.e. that still exist in the second file, remain deleted from the merged model.
Differences to the same modeling elements:
•If a property (e.g. the visibility of a class) is changed in either the source, or second file, the updated value is used in the merged model.
•If a property (e.g. the visibility of a class) is changed in both source and second file, the value of the second file is used (and a warning is shown in the messages window).
Moved elements:
•If an element is moved in the source, or second file, then the element is moved in the merged model.
•If an element is moved (to different parents) in both the source and second file, a prompt appears, and you have to manually select the parent element in the merged model.
Diagram differences:
UModel first checks to see if there are differences between diagrams of the two models. If yes, then the new/different diagram is added to the merged model (with a running number suffix, activity1 etc.) and the original diagram is retained. If there are no differences, then identical diagrams(s) are ignored, and nothing is changed. You can then decide which of the diagrams you want to keep or delete, you can of course keep both of them if you want.
Source control systems support for 3-way merging
When checking in/out project files, UModel automatically generates "Common ancestor" (or snapshot) files which are then used for the 3-way merge process. This enables a much finer merge result than the normal 2-way merge.
The specific source control system you use, determines if the automatic snapshot 3-way merge process is supported by UModel. A manual 3-way merge is however, always possible.
•Source control systems that perform automatic file merging without user intervention, will probably not support an automatic 3-way merge.
•Source control systems that prompt you to choose between Replace or Merge, when a project file has been changed, will generally support a 3-way merge. After the source control plug-in has replaced the file, selecting the Replace command activates the UModel file alert which then allows you to do a 3-way merge. UModel must be used for the check in/out process.
•Main projects as well as subprojects can be placed under source control. Changing data in a subproject automatically prompts you if the subproject(s) should be checked out.
•Each check in/out action, creates a Common ancestor, or a snapshot, file which is then used during the 3-way project merge process.
| Note: | Snapshot files are automatically created and used only with the standalone versions of UModel, i.e. these functions are not available in the Eclipse or Visual Studio plug-in versions. |
Example
User A edits a UModel project file and changes the name of a class in the BankView Main diagram. User B opens the same project file and changes the visibility of the same class.
As snapshot files are created for each user, the snapshot editing history allows the individual changes to be merged into the project. Both the name and visibility changes are merged into the project file during the 3-way merge process.