Question How to NOT treat deleting with consecutive adding of the same file as change?

The question is in thread title. Is there a way to configure plastic to treat consecutive deleting and adding of the exact same file as NOT a change?

 

Hello!

Sorry I wasn't clear enough in my initial post.
My case is pretty simple:
Firebase sdk goes with a tool called External Dependency Manager. This tool resolves dependencies of installed packages and this tool has "Force resolve" method (basically deletes everything and redownload). Nothing changes, I compare files (not all of them, just two) before and after with fc.exe binary mode, but plastic scm treats it as 126 deletions and 126 adds of the exactly same files. All I want is to teach plastic somehow to treat such situations as no change. At the same time if I delete file manually and replace it with exactly the same binary file - it shows no changes. Which is pretty confusing.

Since yesterday I stumbled upon more weirdness:
1) It's just a small bug:
- Delete some file
- Checkin this deletion.
- Rename the folder that file was deleted from.
- Checkin this change either
- Go to deletion changeset "explorer" (dblclick on changeset in changesets window)
- Right click on file and choose "Undelete revision in specified path..."
- If you try to click browse - there always would be error "Directory must exist"
- The only thing you can do is to manually modify that path string and the whold point of Browse button - to let you choose folder, not print it in from keyboard.

2) Strange ?bug? with undeleted file:
- Undelete some file
- Plastic treats is as addition (Copied(new)) - so far so good
- Delete this file
- There would be deletion in pending changes.
- Thas's deletion of the file that does not exist.

 

Do you have move detection and hash comparison disabled? Try enabling both.



I do remember Plastic sometimes having trouble when replacing a file (outside the client, or even from within Unity WITHOUT the VersionControl plugin/package), assuming a deleted-and-added instead. In these cases I usually undo the change/rename, and explicitly rename/move the file from within the Plastic workspace explorer instead. But this of course is not feasible if your automated external tool touches hundreds of files...

 

Hello and thank you for your reply.

Yeah, I got those flags checked. I resolved my problems by disabling Unity Version Control inside Unity editor. No more random checkouts of touched files. External Dependency Resolver from now on is free to do whatever he wants and in pending changes would be actual changes not just EVERYTHING that have been touched. It actually makes Plastic usable without pain.