Plastic SCM shines at merging branches, its merge core can detect a significant number of different conflicts, the "Loaded twice" is one of them, you can read the full list here: https://www.plasticscm.com/mergemachine
All the Plastic SCM merges use, at least, three contributors, the "Base", the "Source" and the "Destination".
The "Source" contributor is the changeset "from" the merge operation runs. The "Destination" changeset is the changeset "to" and where the merge result will be created. Finally, the "Base" contributor is the common ancestor between the "Source" and the "Destination".
Loaded twice conflict
The "Loaded twice" conflict usually happens when an "added" item has been cherry picked from the branch you try the merge operation. Let's review the scenario with an example:
The first changeset at the /main/task162, changeset #7, has been cherry picked to main creating the changeset #8:
Changeset #7 contains an empty "settings.txt" file:
And so it does changeset #8 at /main. Changeset #10 at /main/task162 add "A, B, C, D, E" to the "settings.txt" file, on the other hand, changeset #9 adds "1, 2, 3, 4, 5" to the same "settings.txt" file.
Merging "/main/task162" to "/main"
A merge operation from "/main/task162" to /main" will show the following conflict:
The merge operation finds an "Item loaded twice" conflict for the "/Config/settings.txt" file, why?
Well, the "Explain merge" button can help with that, the following image shows the changeset contributors for the merge operation:
Changeset #5 is the "base", changeset #9 the "destination" and changeset #10 the "source". The Plastic SCM is all about comparing trees to know which conflicts the system has to solve. Both the changeset 9 and changeset 10 load the "settings.txt" file but the base, changeset 5, doesn't.
The "settings.txt" file has been integrated from "/main/task162" branch to "/main" using a cherry pick operation. As the file is not loaded at the base contributor, changeset #5, the system doesn't know when and who added the file. The cherrypick operation is not taken into account for the merge operation.
The conflict has to be resolved by choosing one of the two contributors, that will take the changes introduced in changesets #10 (source) or #9 (destination).
How to avoid the "loaded twice" conflict
It's essential to understand how the cherry pick operation works. Cherry picking added items from a branch that is going to be later merged can result in "loaded twice" conflicts because the base changeset doesn't have the file loaded. So the first step is to try to avoid this kind of scenarios, if that's not an option then, we recommend to continue cherry picking the rest of the branch.
The cherrypick operation can work for a single changeset or a changeset interval; the example has only one changeset left to be integrated, so an additional cherry pick for changeset 10 results in the following operation:
It's a regular file conflict; the Plastic SCM client allows the user to resolve the conflict and finish the branch integration.
- Cherry pick: https://www.plasticscm.com/documentation/advanced-version-control-guide#cherry-pick
- Interval cherry pick: https://www.plasticscm.com/documentation/advanced-version-control-guide#interval-merge
- Cherry pick Vs. merge: http://blog.plasticscm.com/2012/05/cherry-pick-vs-merge.html