Item loaded twice conflict

[JakubH]

We have one serious issue here. I just find out that if somebody add a new file in one branch, cherry pick that changeset to a child branch and after some time he/she wants to merge from the second branch to the first one, the file cannot be merged!

 

I knew already about an evil twin conflict and the inability of Plastic to solve this type of conflict by a merge. I thought that a workaround to this is to make sure to check-in a file in one branch only and cherry pick it to other branches if needed. Now, I see it is not always a solution. In the described case the problem is even hidden, because Plastic offers an option to View content of the item loaded twice only (which looks like there is only one version of the file, so no merge is actually needed) but this is possibly not the sole version of that file. There might be a different revision in the other branch. What user typically wants is to merge those two revisions, but he/she can't!

 

I don't understand why. May you bring some light into this area?

 

(My primary system is still Plastic 4.1, I haven't tried this in Plastic 5 yet.)

[calbzam]

Hi,

 

When you perform the cherry pick operation, it doesn´t keep traceability as merge does. When you try to merge the task branch in the main branch, there is not a common ancestor and you get the loaded twice conflict (Plastic always does a 3 way merge)

 

We have a task to improve this kind of scenarios. Actually, this is a variation of the linked user voice request (based on the same concept). It´s in our roadmap to improve these scenarios, but voting in the user voice page is appreciated.

 

Regards,

Carlos

[JakubH]

Um. That's a trap. There is a cherry pick operation, which allows to bring a specific changes to another branch, but it puts the branch in this kind of inconsistent state without an easy way out. I wish there was an optional 2 way merge at least. Moreover, the GUI describing the conflict is really confusing. It doesn't show the two revisions of the file, so it seems that they are the same and therefore no merge is needed. The true is that the merge is needed but Plastic is not able to do that.

 

That user voice request is actually one of the most wanted – top #3, by now. So, I guess I am not the only one encountering this.

[calbzam]

Yes, we are aware that it´s an important feature for many users. Hopefully, we can implement a better way to deal with these conflicts soon. Thanks for sharing the scenario in the user voice ticket.

 

Regards,

Carlos

[gweronimo]

Hi! I'm awakening an old thread since it's related to the above mentioned uservoice.

 

Would it not be possible to handle _added_ files/folders in a better way in a Cherrypick? When cherrypicking a file Add operation, a sensible expectation is to be able to merge this back to the branch where the Add came from... Fixing this would solve parts of this related uservoice.

 

Here's a scenario:

 

* Switch to branch /main

* Add file a.txt. Checkin (1).

* Add file b.txt. Checkin (2).

 

* Switch to branch /other

* Merge from (1). Checkin (3). "Copied (new) / Merge from 1".

* Cherrypick from (2). Checkin (4). "Copied (new) / Cherrypick from 2".

* Modify the contents of a.txt and b.txt. Checkin (5).

 

* Switch back to branch /main

* Modify the contents of a.txt and b.txt. Checkin (6).

* Merge from (5).

 

Now, you get a "Item loaded twice conflict" on b.txt that was cherrypicked earlier. On a.txt that was merged earlier you get no such problem, only a normal conflict.

 

Could not the Cherrypick operation be modified to include the necessary info to be able to merge it back later?

 

If we had done a (no-change) Merge from (4) back to /main before the modify-checkin (6), the following merge from (5) would have worked just fine. That seems to indicate that not much extra info is needed to get it working as expected.

 

Thanks,

Göran

[manu]

Hello Göran,

 

thank you for the suggestions.

 

We can certainly improve it and once we accept the uservoice request we'll manage to implement it in the best possible way.

[gweronimo]

Hi Manu! I want you to pay special attention to my very last comment. It means that there is a possible workaround in some cases:

 

After a cherry-pick involving added items, immediately do a normal merge back onto the original branch (the one you cherry-picked from). Of course, this is not always feasible and it will NOT help if the added files have already been modified on the original branch.

 

Please think through what happens in that merge-back, as it will not seem to contain any changes but still it will make subsequent merge-backs work fine even when there are changes to the added items on both branches (no more "item loaded twice"). These hidden details that happens in this "magic" (seemingly empty) merge-back is exactly what I'd like you to do in the original cherry-pick, so we don't get this problematic issue in the first place...

 

Thanks,

Göran

[gweronimo]

Hi Plastic team! I'm awakening this thread since I never got a comment on my findings from my last post, and since we  again stumbled on this issue today (with latest stable version 6.0.16.1765 on Windows)...

Cherry-picking added files is still problematic, and seemingly unnecessarily so!

/Göran

[manu]

Hi @gweronimo!

yes, we are aware of it but we couldn't improve it so far...

[gweronimo]

Hi @manu,

Yes, but have you thought about my comments regarding the internal effects of a "add-cherrypick-mergeback" cycle, where the last step results in a seemingly empty merge changeset that apparently resolves the issue for further merges? I think it contains important hints for how to improve this...

Best regards,
Göran

[Scott Courtney]

I'm going to bump this necrothread, to report that one of my colleagues encountered this bug, or one very similar and giving the same message, today on the very latest version of Clout Edition.

We're fortunate that he has no changes in the workspace taht we care about preserving, so we're able to just discard the local data, but that might not always be the case.