This is a brand new file I just created. It doesn’t (or shouldn’t) exist in the repository yet. This file was copied from another project folder, so Unity Editor isn’t even loaded (thus its plugins shouldn’t interfere).
Yet I am unable to add this file to the repository using Plastic SCM. Why? Surely it can’t be confused between the material file and the meta file because Unity understands meta files, and Unity owns Plastic, right?
I am also unable to uncheck just one of these files. Checking or unchecking a file will do the action for both files. They’re both either unchecked or checked.
However, if I use the shell integration tool to add these files, then it worked. This confirms (?) it’s an issue with the GUI.
Plastic SCM version is 11.0.16.9080
For what it’s worth, these are what I’ve tried to fix this issue:
- Uninstalled PlasticSCM, re-installed it, and rebooted the computer for good measure
- Deleted the entire workspace folder and downloaded it again
However I have colleagues who are able to add new files with no issues. Even though we’re all using the exact same version (11.0.16.9080)
I’ve tried everything I could think of but I’m stumped.
Can you show what Workspace Explorer shows for this Materials folder? It seems to be griping that the .meta file exists already.
I was able to add it using shell integration. So that strongly implies this is a Plastic SCM error.
Somehow there is in the tree an entry with the same name/path.
Are you using cloaked.conf rules?
I guess the issue still persists if you use the Version Control package inside the Unity editor?
Could you open a ticket at devops-vcs-support@unity3d.com? We can try to arrange a meeting with you to debug it.
I just ran into a similar thing. It’s not something I normally see. You know what I was doing differently? I had View As Tree turned on. Almost never use it. I switched to viewing pending changes as non-tree and checked everything in with no issue.
Huh. I also have View As Tree turned on. Never would’ve suspected that would’ve been the case! I’ll give that a try.
(If this is the issue, then it’s super concerning that an UI option would cause submits to fail because that implies there isn’t sufficient separation between UI and logic)
I have no idea what a cloaked.conf rule is so… probably not?
It’s not 100% reproducible either. Sometimes I’d add files just fine, but then if I try to add a whole bunch of files (e.g. added a new package, or an asset folder, etc.) then I’d end up with errors blocking the add.
Adding via shell integration is my current workaround. I don’t use the Version Control plugin because I don’t trust it to not interfere with Plastic SCM when I’m already having issues with it.
I’ll turn off “View as Tree” and will post here if I still have more errors afterwards.
Yep, that (the tree view) is what gave me that “aha” moment today. My error wasn’t exactly the same, so that makes me wonder if it’s the same issue. But it was the same in nature of “we already have this thing you’re trying to add.”
I also don’t use the Unity integration because Unity is so unstable. Workspaces can be a bit fragile. I had to rebuild my workspace because the Plastic GUI got into a state where it just threw Unexpected Error when I was trying to undo changes. I just got off a call with one of our engineers whose power went out in the middle of a checkin, and now the Plastic GUI won’t let him check in or undo, either. Guess what he gets to do? Given all that, I definitely don’t want to add the extra layer of instability that is Unity.
1 Like
It’s also worth noting that View as Tree was a feature that they ditched when they went to the new UI a few years back, and only recently added back in. I’m guessing the newer code has some bugs in it.
1 Like
Any chance it was “An item with the same key has already been added” error? Because I’ve seen that error too
Yeah, about 80% sure that was it.
Please keep us posted if the error is only happening when the tree view is enabled.
Can you also attach the Plastic client logs and let us know the time the issue happened?
C:\Users\xxx\AppData\Local\plastic4\logs
Checking the error stacktrace, we may be able to debug and fix the problem.
I haven’t seen errors since turning it off, but I also haven’t worked with a large amount of files yet either, so I’m not ready to call this solved… but I’ll mark it as a tentative solution for now.
I’ll be sure to report back with a log if I see the error again.