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.

[tucny]

…and some 9 years later in Plastic version 11 this bug is still around and causing headaches:

Issues in particular:

• No way to actually diff — I can't choose the resolution method without diffing first. Did anyone do any UX design here?
  • 
• Wrong defaults — again, the workflow is (1st) diff, (2nd) choose resolution and you offer (1) choose resolution and that's it. The diff is burried in the righ-click menu, and for the evil twin only.
  • 
• No show of what is source and destination — would it be possible to explicitly show the source and destination branch path and changeset number in the UI (see the red rectangle)? I did submit these suggestions some years before, but apparently, no one understood why it is a good thing.
  • 
• Bad contrast — please fix the dark gray text on light gray text, see screenshot above. Did anyone do any UX design here?

Please, please, fix this 🙏, @manu, @calbzam.

Note: Yes, I know there's the new GUI. It's so buggy and functionally behind the old one, that we can't use it in production. I did it a try, and sent some 30+ bug reports and UX hints, but can't use it as long as I get the following error twice a day:

And this one when trying to do the same merge as above with the old GUI, so I even physically cannot do the same merge with the new GUI:

I am using version 11.0.16.8077, so the latest. And no, I can't upgrade the client every week, unless there is a significant step forward in quality and feature-parity.

[calbzam]

Hi,

if you have some issues or feedback about Plastic SCM / Unity version Control please open a ticket with us or use the Unity forums: https://forum.unity.com/forums/unity-version-control.605/ 

I can see you are using the legacy GUI for your initial feedback. This GUI was deprecated and removed from the installer. We need to review what of these errors are happening in the new GUI and fix them (not necessarily to use the very last Plastic version but at least the new GUI).

Quote

Note: Yes, I know there's the new GUI. It's so buggy and functionally behind the old one, that we can't use it in production. I did it a try, and sent some 30+ bug reports and UX hints, but can't use it as long as I get the following error twice a day:

Are you using AD authentication? If you open a ticket with us, we can propose a workaround to mitigate this error.

 

Quote

And this one when trying to do the same merge as above with the old GUI, so I even physically cannot do the same merge with the new GUI:

Please open a  ticket with us so we can debug the logs and fix this problem.

 

Regards,

Carlos.