Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Content layer
id1993946884


Content column
id1993946886


Content block
id1993946885

There are two types of model merge that can be used to merge two selected project versions (source and target):

  • 3-way merge
 and 

  • 2-
way merge. Choose the
  • way
of
  • merge
according to a particular case.

3-way merge

Conceptually, The 3-way merge is a junction of two different sets, if we assume that a different set contains changes between a contributor and the ancestor. For example, a different set of v1-v2 represents changes between project v2 and ancestor v1 as well as v1-v3 does for project v3 and the same ancestor.

Use the 3-way merge, if you need to compare and merge changes from two projects into one and consider the ancestor of both projects. For example, you may need to merge two branches of the same server project that have been simultaneously developed by two different users in a collaborative environment, as shown in the following figure. As you can see, branch b.1 has been created from project version 2. Then both versions have been developed in parallel. The merge operation copies changes that have been made in the branch version to the trunk version.

allows merging both local and server projects. To merge two selected project versions, the common ancestor (a common project version for both target and source) is used. The common ancestor is calculated automatically when working with Teamwork Cloud projects; however, you have to select a correct common ancestor manually for local and Teamwork Server projects. This is the recommended way to merge project versions because the 3-way merge is able to identify the changes made in the source and target project versions separately by comparing changes between the ancestor and both contributors. This allows merging the selected project versions more smoothly. 

Image Added

Visual representation of the 3
Image Removed
 
2
-way merge

2-way merge

The 2 is a specific case of the 3-way merge . Use this type of merge for joining together two versions of the same local or server project. The logic of this type of merge is the same as of 3-way merge. However, the ancestor project version for TWCloud projects is found by using the following algorithms: 

  1. The lowest common ancestor (LCA) of two revisions v and w in a tree, or directed acyclic graph (DAG) T is the lowest (nearest) revision that has both v and w as descendants. Each revision is defined to be a descendant of itself (if v has a direct connection from ww is the lowest common ancestor). The LCA of v and w in T is the shared ancestor of v and w that is located farthest from the root. This algorithm considers both the direct parent path and merged path of v and w when finding a common ancestor. So, it can produce more than one common ancestor between v and w, if those lowest ancestors have the same distance from v and w.
  2. The lowest common ancestor (LCA) of two revisions v and w in a tree, or directed acyclic graph (DAG) T is the lowest (nearest) revision that has both v and w as descendants. Each revision defined to be a descendant of itself (if v has a direct connection from ww is the lowest common ancestor). The LCA of v and w in T is the shared ancestor of v and w that is located farthest from the root. This algorithm considers only the direct parent path of v and w when finding a common ancestor so there can be only one common ancestor between v and w.

Which algorithm will be used for a particular merge case depends on previous target project commits: 

  1. if there are Set As Latest and merge commits among previous target project commits, then the algorithm will be chosen by the rule which commit is the closest to the current target project:
    1. if the closest commit is from Set As Latest then the second algorithm will be used;
    2. if the closest commit is from same source project merge then first algorithm case will be used.
  2.  The second algorithm will be used if previous target project commits were not set as latest or revert commits; does not have merge commits of the same source project.
Image Removed

compares two local or Teamwork Server project versions selected by the user. Typically, the target version of the project is considered to be the common ancestor (a common project version for both target and source). As a result, only the differences between the source and the target project versions are identified. 

Image Added

Visual representation of the 2-way merge

Merge in Teamwork Cloud 

The 3-way merge is the default merging method used to merge the selected Teamwork Cloud projects. It means that the correct common ancestor version is specified automatically and there is no need to select one manually. 

This is how the common ancestor is calculated:

  • The lowest version of the trunk a branch was created from (it contains the latest changes both from the source and the target project), e.g., version #2 is considered the common ancestor version of the projects being merged. Once the correct common ancestor for the two selected project versions is calculated, a merge dialog is opened. In the merge dialog, you can review changes and accept/reject them. Once you are done, click Finish Merge and commit the changes to Teamwork Cloud. A new version, e.g., version #6 is created. 


Image Added

Automatic common ancestor calculation in Teamwork Cloud

Repetitive merge

When two selected branches are merged several times, i.e., it is not the first merge, e.g., version #4 is merged with version #5 and then version #7 is merged with version #8, the latest common version (merge result) is considered a common ancestor. In this case, version #6, which was produced during the very last merge (when version #4 was merged with version #5), is used as the common ancestor of the source and target project versions because it contains data from both selected branches. This helps to prevent repeated merge decisions made in previous merges.



Image Added

Automatic common ancestor calculation when there are repetitive merges

Set as latest

When the earlier version of the project is set as the latest version, e.g., version #9 is reverted to version #8 and then the result of two merged versions (e.g., version #10) is selected for merge with another project version, the common version that is closest to that specific reverted project version is considered the common ancestor.

Image Added

Automatic common ancestor calculation when Set as latest is used
Note

Please note that these common ancestor calculation rules are used only if the modeling tool and the Teamwork Cloud server are both of 19.0 SP3 or higher version.


Content block
id1993946883

Related pages



...