Checkin operation cannot be started because there is a merge in progress

[DavidJ]

We have an issue where our developers keep getting into a state where they can't progress with a checkin in Plastic

Here's what's happening:

1) Developer makes a change in a file

2) Main branch also has a change to that file

3) Developer attempts to checkin file to main

4) Plastic asks to perform a Merge

5) Merge window is brought up and the developer changes his mind and selects Exit without Saving

6) Plastic is now in a state where they can neither checkin nor rollback. The only obvious way out of it seems to be to undo all their changes and lose their work

I've seen some talk in the forum about introducing a 'cancel merge' button for when you have pending merge links but you want to back out of the operation. Did this ever get implemented?

 

[calbzam]

Hi, 

When performing a merge, if you decide not finishing it, you have different options:

- Re-run the merge from the branch explorer view, solve the pending conflicts and finish the merge (then you can checkin).

- Undo the changes.

- Shelve your pending changes so you can apply them later.

Not sure if I understand your point, or am I missing something?

Regards,

Carlos.

[DavidJ]

Thanks Carlos, generally what our developers want to do is cancel the merge and get their workspace back into the state it was before the merge started. So it looks like the way of doing that is to shelve their changes, undo all changes in their workspace, and then reapply their changes - is that right?

We also have an issue when trying to continue with the merge related to exclusive checkout files. Plastic tells us we need to update those files to avoid merge conflicts but won't let us update because we're part way through a merge. What should we do here?

 

 

[calbzam]

Hi,

- Well yes,  shelving could work as a workaround in this scenario. We are going release a new preference very soon so when enabling it, it will be mandatory to commit your local changes before running the merge. This way, you won't get in scenarios like the commented in this post. 

- If you are modifying in paralel the unity scenes, why do you configure locking for them? The locking/exclusive checkout is recommened for not mergeable files so you are sure nobody is changing this file at the same time as you. If you have the locking enabled, you will need to update your workspace to the last revision and release the lock so during the merge operation Plastic can check the file out and finally commit the merge result.

- If you don't have a good solution for merging the .unity files, you should follow the exclusive check-out workflow so only on person is modifying the file at the same time and no merge conflicts will appear. By the way, are you are of Guon? This is our GUI for artists:

https://www.plasticscm.com/gluon.html

Best regards,

Carlos.