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.
As developers we require strong merging in order to support best development practices such as:
parallel development refactoring
The Branch Explorer simplifies the merging process and helps the user understand the entire branching and merging workflow.
more info
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 infoNo limits in which files you touch to fix a bug or create a new features, hence removing bottlenecks that kill productivity
Keeping the code quality high reduces maintenance costs in the medium and long terms. Software development used to have a truly pessimistic idea regarding how development costs evolved through time, but keeping them low is the key behind the success of many software companies, empowered by the refactor technique:
The Branch Explorer simplifies the merging process and understanding the entire branching and merging workflow.
It is able to:
Figure . Complex branch and merge situation rendered by the Branch Explorer. Changesets from different sources in different colors.
Figure . Branch subdiagram showing only the pending merges to Fix-4.1. Changesets coming from different repository replicas are rendered in different colors.
Figure Branch Explorer explaining the merge contributor
Figure . Branch Explorer showing an in-progress subtractive merge from interval
Creating branches fast is key to implement 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.
The difference between the older version controls and the newer ones is related to their capabilities to create branches fast.
Older systems like Subversion, CVS, Perforce and others, relied on some sort of “copying” to create a new branch, which means it is a time consuming operation. The copy can be optimized to be light, but as soon as it is proportional to the number of files in the branch… it will end up being a blocker for branch creation.
Plastic SCM uses the newer paradigm where a branch simply “inherits” from a given changeset, then creating a new branch is not tied to the number of files in the codebase, the time is linear, and as low as just a few miliseconds, even when the system is handling more than 500k files on the branch.
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 chagesets “2” and “4” inside the branch “main/task01”.
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”.
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.
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”.
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.
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.
Download Plastic SCM