Like finely tuned, crafted car engines outperforms mass-produced engines, Plastic SCM's merge engine throttles with precision and power unseen in the industry. Unparalleled edge case coverage, turning near-impossible cases into cake.
As developers we require strong merging in order to support best development practices such as:
The Branch Explorer simplifies the merging process and helps the user understand the entire branching and merging workflow.
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.
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:
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.
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.
The following picture shows how Plastic SCM is able to track the move and also find the file as modified by the two contributors.
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.
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:
The picture shows how Plastic SCM specifically handles the change/delete conflict helping the developer doing the merge to find a safe solution.
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.
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:
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.
This case involves one developer moving a file and the other deleting it in parallel.
The simple case can be described as follows:
The complex case will involve using one directory. Suppose the following scenario:
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).
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.
The simple case is as follows:
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.
What if the result of two directory moves creates a cycle? This is exactly what this scenario is about.
The case of cycle move is as follows:
The directory cycle can be more complex:
The cycle move is a really complex scenario. The picture below shows how Plastic SCM specifically handles the case.
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:
Consider the following case:
The following picture shows a moved evil twin scenario (the complex case described above) and how Plastic SCM specifically deals with the situation.
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 the changesets inside the branch "main/bug2061".
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 "15" instead of the entire "main" branch. You'll run a "cherry pick" from changeset "15".
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/task10/task12" branch, but not the changes made on "main/task10". 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 below.
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 "6" to "8" (actually [6-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".
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 "92", but you still want to preserve the ones done in changesets "93", "94" and "95". You can "subtract-merge" changeset "92" and get a new changeset "96" with the changes of "93", "94" and "95" but without the ones of "92". 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.
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/scm121" like in the figure and you can "merge-to" branch "main" to branch "main/scm141" directly creating a new changeset. You do not need to switch your workspace to "main/scm141" before doing that and the new changeset 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.
