Merge behavior on same branch

[tony707]

Hi,

 

I'm running some tests on plastic 5.4.16.639 (windows) when merging on the same branch and have some questions:

 

FYI: The repo was configured so that Unity scene files need exclusive checkouts (but don't require head).

 

Let's say I am modifying an outdated file (unity scene) because I am not up to date on my branch.

When I want to checkin my pending changes, I am notified that new changes are available on my branch (-> View new changes).

 

 

1. The Unity scene file is detected as "Changed in source".

 

Don't it should be marked as "Changed both in source and destination" ?

This way I could select the contributor I want to keep ?

 

2. If I click "Process all merges", a window pop up says this file needs exclusive checkout and is not up to date in my workspace and that I need to update.

 

This is nice except the fact the merge link is still done on all the other files ? Won't it be safer to cancel the merge process to let the user undo his file changes ?

Then the update/merge view is not recalculated and let me "process all merges" again. This creates a mess because some files a merged twice.

Moreover the scene file is then automatically opened in the merge and differences tool to resolve the conflicts manually.

 

-> You may know these files cant be merged manually, so I just exit without saving in order to choose the contributor to keep but it doesn't work, nothing happen.

 

-> The only solution is then to shelve the pending changes to undo the merge link

 

 

3. If I recalculate the merge after the popup, the file is finally detected as "changed in both source and destination" and I could choose the contributor to keep

 

 

Let me know if you can reproduce this scenario

 

Thank you very much.

Anthony

 

 

 

[tony707]

Any updates ?

[manu]

Hi Tony, 

 

We removed the "requirehead" feature time ago, your release should be ignoring whether that keyword is present or not. Now the exclusive co is always requiring the head.

 

The behavior you are getting is weird, do you have both the client and server upgraded?

 

Do you think it's possible to schedule a fast online meeting to review the case with you?

 

Best regards,

Manuel.

[calbzam]

Hi @tony707,

 

I can reproduce the issue and we are going to protect this scenario, but I would like to get more information of your workflow because I think that we could avoid this kind of issues.

 

You comemnted: "Let's say I am modifying an outdated file (unity scene) because I am not up to date on my branch". If you are going to modify an outdated file, first of all you should check it out. If your coworker is working on it, your will  get an error message and you will not be able to work on it. If it´s available to modify, you will not get the exclusive checkout error and you will be able to perform the commit.

 

 

In summary, I would recommend you first to try to checkout before modify all the files that are likely to be blocked. Make sense fot you in your scenario?

 

 

Regards and thanks forn your feedback.

 

Regards,

Carlos.

[tony707]

Hi,

 

Yes it makes sense to checkout the files before modifying them but

1. In our scenario only some file types need/can be checkout.
2. It happens some artists forgot to checkout some files and leads to the same following case

 

We are mainly working on a main development branch and our concern comes from the fact the diff view is not the same

in pending changes / branch diff view and branch / branch diff view.

 

To be clear if one user checkin a file another is also modifying locally, the other diff view won't show this file as "changed in both source and contributor"

but only as "changed only in source". But this can still lead to a merge conflict once he processes all merges.

 

I don't know if this is clear Let me know if you need some more details.

 

Thank you!