Since Plastic is now part of Unity, it would be fantastic if you could address meta files. Because the difference between two meta files is usually only the guid, it considers any two meta files close enough, so they constantly get marked up as moved - even though one is added and the other deleted.
So in my opinion, meta files should get special treatment. Maybe they should get matched up with the files they’re for. Or have a lower threshold for change detection. No idea. Something better.
Could you explain that in more detail when that happens? Only when you both add and delete a .meta file in the same commit?
What I don’t understand is the “close enough” part of it. Usually a VCS would understand a move only if both files are identical, expect path and filename. Not sure if VCS uses a threshold but if so, that seems broken because it could consider any two files with similar content as a move.
You could verify this behaviour by adding two default scripts that are identical or differ slightly, and then do the add/remove. That should do the same thing, right? Otherwise maybe you misunderstood something about the “marked as moved” aspect, perhaps due to a GUID desynchronization (same .meta file with different GUIDs on different machines).
If you use the Unity Version Control plugin to move the items, it should properly consider the .meta files.
It should also properly track the moved item. If you do the moves under Plastic control (using the Plastic GUI in the Unity editor when the plugin is enabled), it doesn’t need to guess what happened on disk and try to match the moves; it will properly track them.
I guess you are performing the changes on disk and then Plastic is trying to guess what happened, right? The algorithm to track the moves on the disk is not making any special consideration for the .meta files and it’s not always 100% accurate (especially if the files are also edited or if they are binary files)
Sorry that it was so unclear.
So indeed the use case is: A bunch of files has been moved around on disk including their meta file. Not using the Plastic GUI (I hate using the Unity plugin and don’t trust it, but also, we use other tools).
Now the problem is, most meta files are 99% the same, only the guid is different; so it quickly matches up different meta files wildly across folders, thinking they’re valid moves (and that the guid has changed).
Often, after working with files for a few minutes, you’ve moved some files, added some new ones, removed some. So it quickly becomes a messy situation.
If I’m not mistaken, 100% equal files don’t get matched up first as moves, and “mostly similar” files afterwards. It just arbitrarily matches them up with each other.
If you do those file operations outside the editor, you’re not supposed to do that. This can easily cause issues with the project, with or without using source control.
If the editor causes domain reloads all the time while organizing files/folders, then just disable asset auto-refresh in settings for a while.
I’ve been using Unity long enough to know what causes issues with the project (18 years). My project is fine. It’s just that Plastic matches up files that are not supposed to be matched up.
There is no way to correct it, so it creates an invalid history of almost all meta files. This is a minor nitpick, because long-term it does not matter at all. It’s not like someone will go through the history of a meta file. It’s just annoying to see that it does it.
Could you clarify a bit more about the issues you have had with the Unity plugin in the past? Have you tested the latest version?
For my own opinion, I will not use or recommend using a Unity plugin to do any version control operations simply because Unity is too unstable. Depending on what you are doing (editor scripts are especially bad) and how big your project gets, you’ll find Unity crashes or hangs are not uncommon. I don’t want my version control operations mixed up in such an unreliable platform.
While I understand that it’s a difficult job for the algorithm to track moves, I agree with the OP that there should at LEAST be a special check that for .meta files, it should do some extra work to take the guid into consideration.
I’m not 100% sure how that will look in practice, but there’s got to be some improvements that could be done there. One example would be that if it saw a .meta that has the same guid, it could know that is the renamed file.
Even with just renaming files within Unity (not in the filesystem) without using the Unity plastic plugin (because of issues noted), I have seen plastic do some very questionable detection of renames, especially when those renames came with changes to the file as well (like maybe changing an import option on an FBX).
We generally recommend everyone do all renames/moves separately in a different cs, with ZERO changes to the actual file itself so that plastic doesn’t screw it up.
The ideal approach is that all the file moves/renames are done via controlled changes (using the Unity plugin, Plastic GUI, cm move). This way, we won’t need to guess what happened on disk.
Depending on the size of the file and the changes applied, it would be easier or not to track the moved files on disk.
You can also customize the move detection ratio:
We also have an inernal task that is not still planned that should be helpful to better manage the
When you rename a file in Unity the corresponding .meta file gets renamed as well. When you rename a Unity file in the GUI, you need to rename the associated .meta file as well, thus making the process slower, tedious, and prone to errors (for example, if there is an update operation run). Propagating the rename could prove very beneficial to users using the GUI.
That is more of an ideal from a programmer of Plastic side than it is from a user of Plastic side, though. As a programmer, I get where you are coming from. But that’s just not the way that’s desirable for a lot of programmers, artists, etc. in the real world. Especially when not everyone is a technical expert.
I have played with the move detection a lot, including having to completely disable it (as I had to do about an hour ago, even, because it detected some similarly named .wav file and thought they were the same - even though they were totally different and it’s just because their filenames both included dates). And of course that’s something that’s way easier for a more skilled user to fiddle with. I’d say half our studio is just not going to be at that level.
I think the task to propagate the rename will be helpful. As would be tasks where you show a little extra love for Unity by analyzing the meta and yaml more intelligently.
Could you clarify a bit more about the issues you have had with the Unity plugin in the past? Have you tested the latest version?
It has been slowing down Unity, acted unreliably, and added clutter to the interface. Unfortunately, I don’t have enough time to experiment. Generally, using the Plastic software (Unity DevOps Version Control) next to Unity works fine. It’s just bad at matching .meta files with their tracked file. Which, calling itself “Unity DevOps Version Control”, I would expect to work better.
You can also customize the move detection ratio
I’m aware of this and constantly have to fiddle with it until it guesses most of the move operations correctly. If you have more than a few files, this is tedious, and usually, I end up just committing whatever. For meta files the history connection is not that essential.
I agree with Jason that what you’re suggesting regarding the ideal approach is indeed an ideal. Actually working with files is a lot more fuzzy than that and you can’t expect all rename/move operations to always happen inside Unity. Unity is mostly capable these days to link up moved files to their guid correctly, so the Unity Version Control tool should be as well.
