Plastic showing status Changed when files are identical

[prog112]

I got an issue with a bunch of files that Plastic marks as Changed even though they appear to be identical when diff'd.

 

It can happen with multiple files (.asset settings files or materials). What's going on?

 

 

[calbzam]

Hi,

Is it possible that the file timestamp has changed? You can change this default behavior If you open the Plastic GUI --> Preferences --> Other options --> Check content to set a file as "Changed".

Regards,

Carlos.

[prog112]

1 minute ago, calbzam said:

Hi,

Is it possible that the file timestamp has changed? You can change this default behavior If you open the Plastic GUI --> Preferences --> Other options --> Check content to set a file as "Changed".

Regards,

Carlos.

Yes, that did the trick!

 

Is there any option to set this on the repository level itself? Or does every team member have to go and tick this in their client's preferences?

[calbzam]

Hi,

This is a local client configuration setting (not configurable on the server-side). By default, the "Pending changes" is not checking the file content (only the timestamp), because it would take a very long time in big workspaces with slow disks. Checking only the timestamp is very fast.

Anyway, if you try to check in an item that appears as changed in "Pending changes" but the file content is actually the same (not changed), Plastic won't create a new file revision in the repository.

Regards,

Carlos.

[prog112]

6 hours ago, calbzam said:

Hi,

This is a local client configuration setting (not configurable on the server-side). By default, the "Pending changes" is not checking the file content (only the timestamp), because it would take a very long time in big workspaces with slow disks. Checking only the timestamp is very fast.

Anyway, if you try to check in an item that appears as changed in "Pending changes" but the file content is actually the same (not changed), Plastic won't create a new file revision in the repository.

Regards,

Carlos.

I understand that but for consistency issues having items which are not really edited in that list will certainly cause needless misunderstandings. Not only that,  but it litters the changes list so it's hard to gauge what you've truly changed. It is be something that now will have to be explained to every new team member.

[Wolfram]

On 7/10/2019 at 2:24 PM, prog112 said:

I understand that but for consistency issues having items which are not really edited in that list will certainly cause needless misunderstandings. Not only that,  but it litters the changes list so it's hard to gauge what you've truly changed. It is be something that now will have to be explained to every new team member.

We've gotten used to always do an "Undo unchanged" before any commit (=before going through the list to check the changes), it will remove any unmodified items from the list.
The only danger is to accidentally do an "Undo changes"...so always double-check you selected the correct drop-down entry 😉