Deleted a folder in Unity and now my changeset looks really messed up

[jwvanderbeck]

Migrating from Git to Plastic for a Unity project.  As I didn't use Git anymore, I deleted the Github for Unity plugin folder from my Unity project and the resulting changeset from Plastic in the GUI looks completely wrong.  Basically it seems to think I moved files but the files it is connecting up to are completely wrong. 

All I did was delete the directory Assets/Plugin/GitHub (along with all the files and subdirs in it of course)

How can I fix this? I haven't commited my changes yet.

[Mikael Kalms]

Hi jwvanderbeck,

I've used Plastic when developing a game in Unity previously. Perhaps this helps a bit:

1) It appears that your client is not configured to ignore the Library/ folder. Git has ignore rules in a .gitignore file; Plastic has ignore rules in an ignore.conf file (docs here). The syntax is similar, but not identical; complex nested exclusion/inclusion rules do not work the same, and brackets [ABC] notation does not work the same. Also, ignore.conf must be at the root of the repository. If you have already added the Library/ folder, either delete the thing - or nuke the repository and reimport your entire project, so you get a clean history when starting off.

2) It appears that Plastic's automatic move detection is not working like it should for you. See the 'similarity %' in the right-hand column? If there are both deletions and add operations on your local machine, then Plastic tries to pair them up by looking for delete/add pairs that have similar content. I'm surprised that it arrives at such high similarity %s for those file pairs -- the matches like "from sfw_x86.dll to UnityEditor.TestRunner.dll" do not make sense to me; perhaps someone from Codice Software can explain that if necessary.

Mikael

[calbzam]

Hi,

As Mikel comments, when you perform changes out of the Plastic control (directly ok disk) Plastic can only guess what happened checking the hard drive. 

You may have deleted these folders but according to the "Pending changes" view, a very similar folder has been added on a different location. That's why Plastic considers it a "move" instead of a "delete". If you check the "Similarity" column, the values are very high (it means the file content is very similar and Plastic considers it a "move").

Could you focus on any of these files and confirm these similarity values?

Regards,

Carlos.

[jwvanderbeck]

1. The issue of the ignore.conf is something I needed to look at.  I actually did configure one for the project on another machine so I' not sure why it isn't taking effect on this one.  

2. I only deleted that one folder, I did not add new files, however with Unity files often get updated and what not in the Library folder.

However it happened, it seems seriously odd to me that Plastic considers these files to be similar enough to be the same thing when they are completely different files.

I'm pretty much always going to be modify files outside of Plastic so if that is going to be a larger problem than that is a concern for me.

I will look into the specific files as requested when I get int o work in about an hour, but I know they are not the same files.

[jwvanderbeck]

Ok so I looked into this more.  All of the "matched" files are binary so I don't entirely know what algorithm Plastic is using to match them up but I did find that the file sizes are very similar.  Is it only using this?  That would be disturbing.

I reverted everything, then went to work on figuring out why the ignore.conf wasn't working.  Quite simply because it didn't exist.  Having set it up on another machine I would have thought it would be committed to the repo and apply to other machines tht checked out the same project but I guess not.  I added the conf manually on that machine, and then redid the process and this time it worked fine.

So in this case problem resolved, but I do have worries about how Plastic is apparently trying to match up files.  If it is solely based on file size like it appears that seems very likely to get false positives like this.  I would have expected something more robust like at least a fast checksum or hash.

[Mikael Kalms]

Re ignore.conf - good good. It does version like a normal file. 

 

Now regarding similarity, no, it is not supposed to operate just on file sizes. I don't know the exact algorithm but it does operate on content. If you package up one or two 'source' files and corresponding 'target' files that got suspiciously high match rates and submit to Codice Software (or just attach to a post here) then they can give it a look and establish why the matching produced false positives.

[calbzam]

Quote

Now regarding similarity, no, it is not supposed to operate just on file sizes. I don't know the exact algorithm but it does operate on content. If you package up one or two 'source' files and corresponding 'target' files that got suspiciously high match rates and submit to Codice Software (or just attach to a post here) then they can give it a look and establish why the matching produced false positives.

Definitely this is not normal. If you can send us some file examples where Plastic is wrongly considering the same, we will review the scenario in detail to determine the reason for the false positive.

Also thank you @Mikael Kalms for your help :)

Regards,

Carlos.

[jwvanderbeck]

Do you want one pair of files or multiple pairs?  If multiples, any suggestions on how you would like them "paired up" o avoid confusion on which was recognized as which?  Or I could just zip up all the files in that screeshot and you can use it as reference.

[Mikael Kalms]

Zip up all the files in the screenshot, that will work. 

[jwvanderbeck]

This zip file does not include the first false match (For Sirinex.OdinInspector) as that is a 3rd party licensed asset, but all the others are in there as they are Unity files.

https://www.dropbox.com/s/etq0urr5n2snx1j/False Positive Matches.zip?dl=0