Loaded twice merge conflict after a cherrypick

  • Updated

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:

mceclip6.png

Changeset #7 contains an empty "settings.txt" file:

mceclip4.png

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:

mceclip0.png

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:

mceclip7.png

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).

mceclip1.png

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:

mceclip9.png

It's a regular file conflict; the Plastic SCM client allows the user to resolve the conflict and finish the branch integration.

mceclip8.png

 

Useful links