Why does 'Undo Unchanged' almost never work in the PlasticSCM GUI?

Hi, I am wondering why the ‘Undo Unchanged’ option almost never works for me. I added ‘almost’, because I vaguely remember it working sometime in the past at some point. However, nowadays it never seems to do anything. For example, in this situation:

It will not remove the ‘MissionLevel’h’ file from the list of changes when I use ‘Undo Unchanged’. The file is ticked, I have ‘Recognize All’ for the ‘Comparison Method’, and even ‘Check content (hash) when the file timestamp is modified to set it as “Changed”’ set in the preferences. As you can see, Plastic itself recognizes this file as ‘Files are identical.’

I cannot find much on this forum about this problem, and it seems so obvious, so: what am I doing wrong here, or not understanding?

Thanks,
Matt

Hi, I cannot easily reproduce the issue if I change the timestamp of a file so Plastic tracks the file as Changed with no actual changes in the file content.

In your case, are these files just changed in the filestamp? Or has the file hash actually changed? In that case, you will need to “Undo changes” instead of “Undo unchanged”. Some configurations in the Plastic GUI editor may be filtering some file changes: eg: ignore whitespaces… My guess is the file may be changed (different file hash) but we are not seeing the changes in the “Pending Changes” view.

If you can reproduce the issue, we can arrange a meeting and take a look.

Apologies for the extremely late reply. This problem occurs reliably when merging incoming change sets. If you have a conflict when updating a workspace, and you choose the ‘Merge keeping the incoming changes’ option for a file, then the ‘resolved’ file will still be in your Pending Changes, and show up as ‘identical’, but ‘Undo Unchanged’ does not work.

When updating via Incoming Changes, if there is a merge conflict involving a text file, you should be able to merge the content. Why are you selecting to ‘Merge keeping the incoming changes’ discarding your local changes? This is not very common. Anyway, I will try this specific scenario.

If you try to “Undo Changes” (instead of “Undo Unchanged”), does the file disappear from the “Pending Changes” list?

Same problem happens when importing assets between projects - we have a test project for graphic artists and full project for release, any time I import asset from one project to another which already existed before (eg. artists update only material but whole prefab is imported), it shows “Files are identical.” but the files are marked as "Changed" even though I have toggled the “Ignore EOLs and whitespaces” and “Check content (hash) when the file timestamp is modified to set it as Changed”. It seems like it has no effect. Same happens in Plastic SCM app outside of Unity.

Undo Unchanged works only for Chacked-out(unchanged)
Undo Changes makes the file dissapear, but imagine doing it manualy for hundreds of files (for example when importing scene with lots of materials)

Hi Carlos, I don’t see an ‘undo changes’ option in the PlasticSCM UI. I assume you mean using the ‘Undo’ button or menu option on one file at a time? Yes, that works fine. The files then disappear from the pending changes list. But like @sewy says, this requires you to go through the list of files one by one every time

One thing to notice - even git (tortoise git) is suffering from Files are identical due to timestamp. But at least they are showing number of added and number of removed lines, so you can quickly select all files with both 0. In plastic, you have use a per file diff-checker which is problematic when dealing with dozens of “changes”.

If you delete a file and re-import it, even when the file content is the same, the file will appear as “Changed” because is uses the time stamp to determine if a file is changed or not.
If you have this setting enabled “Check content (hash) when the file timestamp is modified to set it as Changed”, the file will not appear in the “Pending Changes” view unless you have explicitly checked-out the item.

I mean the default “Undo” button of the “Pending Changes” view.
You don’t need to click on this button to undo each file change. You can select all the files you want to undo and clicking the button once will undo the changes in all the files.

Anyway, on a normal basis if the file appears “Changed” but the file hash is the same (eg: only the timestamp was changed) I can use the “Undo unchanged” option no issues. If this is not working for you, we will need to debug your specific scenario.

@MattT5 I was trying to understand this specific scenario, could you answer this:
When updating via Incoming Changes, if there is a merge conflict involving a text file, you should be able to merge the content. Why are you selecting to ‘Merge keeping the incoming changes’ discarding your local changes? This is not very common. Anyway, I will try this specific scenario.

As far as I can tell it does nothing to what appears in “Pending Changes”, this bug has been reported multiple times before, even on original PlasticSCM forum here:
https://forum.plasticscm.com/topic/23077-identical-file-diff-still-shows-as-changed-item-although-preference-setting-should-ignore-them/
and
https://forum.plasticscm.com/topic/22522-identical-file-keeps-showing-up-in-pending/#comment-47221

This is a very common when working with more people. Imagine you have some local hotfix, because your coworker is offline, but then he fixes it so you “revert” your changes using Incomming. Similary you know that there could be merge problems (even with text files (or prefabs)), and you know you did only a small thing, so you choose Incomming and redo your small thing.
This leads to the same problem as in my scenerio

The problem is the timestamp, and as I wrote even git has the same one, but at least the show you number of added/deleted lines so you can see what changes without selecting the file (then you are able to select only the files with 0 lines and Undo them together)

Yes, these are two great examples of ‘keep incoming changes’ that I also encounter more often than you ( @carlosalba1985 ) think :wink:

@MattT5 I’ve tried your same workflow:

  1. Merge keeping incoming changes:
    9674000--1378532--upload_2024-3-1_13-22-7.png

  2. There is a changed file but the file content is identical. I can undo the changes and remove the changed file from the “Pending Changes” list:
    9674000--1378535--upload_2024-3-1_13-23-13.png

Why is relevant for you to know to know the changes that happened on a file before selecting it?
If you checkin your changes, Plastic will only create new revisions for the files that have actual changes (different file hash) but it will automatically discard all the files that are marked as Changed but the only change is the file timestamp.

I mean you don’t need to worry about manually undoing the changes for each file marked as “Changed” but doesn’t have actually changes.

It has been already said, that Undo works for but Undo Unchanged does not as it has changes in timestamp.

Because if you know without selecting the file, like in tortoise git for example, you can select multiple files at once and Undo all of them in one click, now you need to go through all of the files to actualy see if “Files are identical”, which takes time if you have dozens of files changed due to export between projects for example.
9674090--1378574--upload_2024-3-1_14-20-19.png

If the Plastic knows if there are no other changes than timestamp, why it shows the file as changed? Most of the time you dont care about timestamp. If you have localy changed only timestamp, you will still get conflicts.

Anyway, it is a convention and a very good practice when working in a team to only commit files that you are sure you’ve changed, and I’m surprised, that I have to emphasize it.

Well, I must admit I did not expect this to turn into a philosophical discussion. Or a ‘you are using our tools wrong’ one.

Fact of the matter is: we are quite often in this situation. Actually, I am in this situation right now. I had to update 202 changelists, download 1.3 GB, solve 30 directory conflicts, and end up with hundreds of files that are seen as ‘Changed’, even though the contents is identical when clicking each one of them (which is fun for exactly 30 seconds).

And why am I in this situation again? Because Plastic got ‘confused’ again, created a merge link for some reason, and marked a thousand files as ‘Replaced(new)’, ‘private’, or whatever it decides sometimes. We get this situation quite often now, where an update fails in some interesting way (is that just us? Are we doing things wrong? Is Plastic getting worse?), and being able to at least reliably undo files that have not changed (both binary and text) would be so helpful.

I could say more, but I have to go and manually undo 68 files now.

Sooo… Is this the end of the discussion? ‘No you are not getting your ‘Revert Unchanged’ like that, because we don’t see the point’? I still think it is a valid use case.

Sorry, I will try to follow up next week after the last comments. We always try to prioritize the paid support. If you are a paying user, please open a support ticket. Anyway, I will review the last comments and follow up as soon as possible.

Note that enabling Ignore EOLs and whitespaces will have the opposite effect - this PREVENT (only) the diff view from showing whitespace changes, so it will often claim the files are identical when they are not.
“Undo unchanged” will NOT evaluate this setting, the files must be truly identical for this.

Also, by definition you cannot undo parts of a pending merge, so if somebody committed something that “seems” identical/unchanged, you cannot undo that particular change (or any other change contained in the merge). You can only manually edit the file to make it match - but this is bad practice, a merge link should always be “clean”, i.e. not contain any other changes, or modified files that have been merged (except to resolve conflicts, obviously).

And, as Carlos mentioned, Plastic will ONLY commit a file if it actually changed - but I get your argument that it is very good workflow to clean up and review your Pending Changes before committing anything.

Not sure about the timestamp problem you mentioned, though. Generally, we never have TimeStamp-only changes showing up (or being committed) in a Windows-only production environment. But if you have team members using Mac or Linux, sometimes Timestamp-only changes will show up in the Pending Changes, and WILL be committed, even if the file is identical.
However, I am assuming you have these checkmarks enabled in the Pending Changes options?
9771684--1400388--upload_2024-4-15_13-10-5.png

Hey @MattT5 ,

I agree this should not be “swept under the rug”, as you have mentioned, this is a huge hindrance to your workflow, and we should correct that.

If you can easily reproduce this behaviour, I would love to spend some time with you in real-time to troubleshoot further and discuss options. If you are open to this, please log a support ticket via devops-vcs-support@unity3d.com.