it is all about merging them back

What the merge engine is all about

What the merge engine is all about

Just like a finely tuned, carefully crafted car engine outperforms mass-produced engines, the Plastic SCM merge engine brings the precision and power no other merge system in the industry can match. No other system handles so many cases, turning near-impossible cases into cake.

The reasons behind strong merging

The reasons behind strong merging

As developers we require strong merging in order to support best development practices such as:

parallel development refactoring
The reasons behind strong merging

Get it rendered!

The Branch Explorer simplifies the merging process and helps the user understand the entire branching and merging workflow.

more info
The reasons behind strong merging

Branch speed

Creating branches quickly is the key to implementing any successful branching and merging pattern. Creating a new branch should take less than a second, even when the codebase is bigger than 500k files.

more info

Making it easy is what Plastic SCM is about!

File conflicts

Plastic SCM provides the only built-in 3-way Xmerge and Xdiff tool that's able to handle complex cases and has moved code support. Here, we'll take a look at Xlink/Xmerge 2-way vs. 3-way merges.

File conflicts

Description

File merging is about combining what developers wrote in parallel to create a new resulting version of the code. File conflicts will only happen when the same file has been modified in parallel. When that happens, a good merge engine will need to locate the three contributors that are always involved in a file merge.

The three contributors on a merge are:

Plastic SCM is able to render it using the Branch Explorer as follows:

File conflicts

A good merge engine will be able to handle many file conflicts automatically. That's why merge-tracking (being able to correctly determine the 3 contributors) is key:

Finally, there will be cases where, as the image above shows, the file has been modified in parallel. That's when you will need a good 3-way merge tool.

Plastic SCM includes its own built-in merge tool capable of turning several complex cases into automatic ones (provided the same line of code is not modified in parallel) and it is the only tool including Xmerge and Xdiff to track code that has been moved and modified.

To learn more about file merging, click here to find out why a 3-way merge is much better than older 2-way merges.

Optionally, you can plug in your preferred 3-way merge tool and still enjoy Plastic SCM's core merge engine benefits.

Files moved and modified

With a built-in 3-way xmerge and xdiff tool, able to handle the complex cases plus the only one with moved code support. Included with Plastic SCM. Xlink/Xmerge Two way vs Three way merge

File conflicts

Description

It is a very common case when the code is being restructured (refactored) and it continues evolving in parallel.

One developer decides to rename a file while, in parallel, a different developer has to make a modification on the file.

The version control should be able to reconcile the two changes together: rename the file and introduce the changes made by the other developer.

But still it is one of the most common reasons why teams avoid branching or are scared of working in parallel: many version control tools fail to handle this simple case and will end up with two files: the renamed one without the changes made by the second developer, and the modified one including the changes but not the rename.

Plastic SCM is able to handle the case correctly.

Simple case

Complex case

How Plastic SCM handles the case - What others do

The following picture shows how Plastic SCM is able to track the move and also find the file as modified by the two contributors.

Files moved

Change/delete

Happens when you modify a file, and somebody else deletes it in parallel. Useful for refactors.

File conflicts

Description

It happens when a developer decides to delete a file and in the meantime it is deleted by a different developer.

Since the new change can be an important one and preserving it key for the project, the version control has to warn during the merge and let the developer choose between deleting the file and preserving it.

Plastic SCM is able to handle the case correctly.

Simple case

Complex case

There are many derived complex cases, since there are several possible combinations.

One slightly more complex case than the simple one involves deleting the directory containing the file that is modified in parallel:

How Plastic SCM handles the case

The picture shows how Plastic SCM specifically handles the change/delete conflict helping the developer doing the merge to find a safe solution.

Change delete

Add/move

You add a file and, in another branch, somebody moves an existing file to the same location. The merge will handle it and let you solve the case.

File conflicts

Description

The conflict happens when a developer adds a file and in parallel a different developer moves an existing file so that it collides with the added one.

The version control system must detect the situation and let the developer decide what to do.

Simple case

Complex case

The complex case will involve directories for this type of conflict. Conceptually it will be similar to the “simple case” but dealing with directories will make it more complex. Suppose the following scenario:

How Plastic SCM handles the case

The add/move conflict is also handled explicitly by Plastic SCM, so the tool drives the developer and shows him the different alternatives to resolve the situation.

Move add

Move/delete

You move a file or a directory into a different location, and in a different branch the destination is deleted. If the version control doesn’t warn you… you could end up losing valuable changes!

File conflicts

Description

This case involves one developer moving a file and the other deleting it in parallel.

Simple case

The simple case can be described as follows:

Complex case

The complex case will involve using one directory. Suppose the following scenario:

How Plastic SCM handles the case

Plastic SCM detects the move/delete conflict and lets the user choose: whether he keeps the deletion or preserves the change (undoing the deletion from the other contributor).

Move delete

Divergent move

Happens when the same file or directory is renamed or moved to two different locations in parallel. The version control should help you setting the right location.

File conflicts

Description

This is one of the best cases to understand the power of a merge engine. It involves two developers moving a file (or directory) to two different locations.

Simple case

The simple case is as follows:

Complex case

How Plastic SCM handles the case

The divergent move scenario is problematic for all version control systems but Plastic SCM is able to deal with it specifically. In case the file was modified in both contributors, the file merge would be handled after resolving the directory situation.

Divergent move

Cycle move

Not so usual but can happen if you move one directory inside a different one (src into code/src) and in the meantime somebody else performs the opposite operation (code intro src/code).

File conflicts

Description

What if the result of two directory moves creates a cycle? This is exactly what this scenario is about

Simple case

The case of cycle move is as follows:

Complex case

The directory cycle can be more complex:

How Plastic SCM handles the case

The cycle move is a really complex scenario. The picture below shows how Plastic SCM specifically handles the case.

Cycle move

Evil twin variations

Evil twins happen when an item with the same name (file or directory) is added in two parallel branches.

File conflicts

Description

There are several types of “evil twins” but they all share the same concept: two different items (files or directories) are added to the same location with the same name. They’re not the same element so they are what we call “evil twins”.

The possible cases are:

Simple case

Consider the following case:

Complex case

How Plastic SCM handles the case

The following picture shows a moved evil twin scenario (the complex case described above) and how Plastic SCM specifically deals with the situation.

Evil twins

Merge types

The Plastic SCM merge engine can deal with different kinds of merges that will be covered in this section.

File conflicts

Regular merge

Regular merge happens when you just need to merge a branch or a changeset into a different branch.

Like in other version controls, the operations to perform are simple: you position yourself on the destination then merge “from” the source. Once the merge is done, your repository (and Branch Explorer) will look like this:

You tell Plastic SCM the “source” and “destination” contributors and it will calculate the “base” (which won’t always be as trivial as in this example) and will help you creating the “result”. The merge-machine is the motor powering the process.

You’re merging into “main” the changes made in chagesets “2” and “4” inside the branch “main/task01”.

Cherry-pick

Sometimes you don’t need to get all the changes you made on a branch but just a single change. In that case you need to use “cherry-pick” merge.

In the example below, suppose you just want to get the changes made in changeset “4” instead of the entire “main/task01” branch. You’ll run a “cherry-pick” from changeset “4”.

Branch cherry-pick

Suppose you want to merge just the changes made on a branch but not the ones coming from its parents. If this is the case, you will be using “branch cherry-pick”.

The figure below shows an example where you want to merge the changes in “main/task01/task02” branch, but not the changes made on “main/task01”. If this is the case, you’ll need to run a “branch cherry-pick” and the Branch Explorer will reflect the scenario with a graphic like the one bewow.

Interval cherry-pick

Sometimes you need to merge changes made between two changesets, but the changesets do not correspond to a full branch. If this is the case you will need to use “interval cherry-pick” as the figure below shows.

You will be merging the changes done in changesets “5” to “8” (actually [5-8] range) and the Branch Explorer will reflect the situation like the graphic above.

Please note that “branch cherry-pick” is just a particular case of “interval cherry-pick”.

Subtractive merge

This is one of the most powerful merge cases that will help you undoing specific changes, like for instance a broken bugfix.

Look at the figure below:

Suppose you want to get rid of the changes made on the changeset “3” but you still want to preserve the ones done in changeset “6”. You can “subtract-merge” changeset “3” and get a new changeset “9” with the changes of “6” but without the ones of “3”. It is like running the merge in reverse order.

Like all Plastic SCM merges it can be run from the Branch Explorer with just a few clicks.

Merge-to

All merges in Plastic SCM stick to this pattern: you put your workspace on the destination then merge from the source.

“Merge-to” is different: suppose you want to “merge-up” some changes from your branch to another one and there can be conflicts like in the figure below:

Your workspace can be set to “main/task01/task02” like in the figure and you can “merge-to” the branch “main” directly creating changeset “9”. You do not need to switch your workspace to “main” before doing that and the new changeset “9” will be automatically created after merge, no need for checkin.

This “merge-to” mechanism is good for some “deploy” scenarios but we strongly recommend to build and test your code prior to checkin a merge.