The option under preferences:
“Behavior when trying to switch/update the workspace with changed items” = Allow:
Does this undo all pending changes and they are lost?
If so that is reckless. It is not documented in the editor window or on the web docs that is what would happen.
If not, where did my changes go?
The assumed outcome (since it’s not documented otherwise) is that the pending changes would come along with the workspace switch with a merge prompt.
Ok, so it looks like I may have deleted my changes by accident?
This window that pops up after switching branches when pending changes are in play.
The window is titled “Update Results” , with a message
“Warning: This file has been changed in the workspace, out of Unity VCS control, so data has been preserved. Item is not up-to-date. If you want to update it try to update forced this item”
I don’t understand this window and it’s not very clear what Update Forced would do, and what closing does without forcing it.
After a few trial scenarios, I noticed that “Update forced” loses the changes in the pending view for the file in question, and closing without pressing it they remain.
You are right. By default, Plastic does not allow you to switch branches with pending changes, but if you do, your changes will not be undone. You need to be careful when following this workflow because you could end up in a situation where you cannot checkin your pending changes later:
The “Update forced” operation, forces the changed items to be downloaded in the branch you are switching. Plastic is detecting that some items were not properly updated to the branch you are switching and it’s asking you to force the update for these items in the branch you are switching.
Can you let us know more details of your workflow? It shouldn’t be necessary on a normal basis to switch your workspace to a different branch with pending to checkin changes.
Quite often it’s necessary to make changes to project files, settings, etc for testing that we don’t want to be permanent.
If I push them before switching branches it makes merging the branch to main much more difficult down the line as I would have to be mindful to remove them during the merge.
And I also want the temp changes to remain active on local when switching around branches. My workload at the moment and in generally requires this. It does appear to behave that way as long as I don’t press the forced button when switching which is good ( atleast on the no conflict basic test I performed in the screenshot above.)
Also, this workflow isn’t that different from pulling updates and dealing with merges conflicts. Showing a update window similar to the one already built would be far more useful than blocking the later pending change push if we did actualy want to push eventually. Being able to use a 3way merge tool in this situation would be very nice.
Why not use the shelving feature in that case? The problem with switching branches with pending changes is that under some circumstances you won’t be able to submit them (see the above link).
But yes, as soon as you don’t run an update forced, the changes won’t be overwritten.