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.