This problem only started showing up in 5.2.0p1, and I suspect it’s related to this change:
“(715960) - Version Control: Do not use cached status for checking editability in VCS.”
In 5.2.0p1, any time you select any version-controlled asset (i.e. anything in your Project tab), the editor immediately becomes unresponsive (on Mac, it beachballs). If you look at the p4plugin.log file, it shows that P4 is spamming the fstat command for the asset you just selected:
That message repeats over and over and over, during which time the editor is completely frozen. If you click around in the frozen editor to deselect the asset in the Project tab, the click will eventually get through on Mac and quit the beach-balling, but that doesn’t appear to work on Windows. On Windows the freeze is unrecoverable.
In short, the nonstop fstat commands make the 5.2.0p1 editor completely unusable in a project that uses P4 for version control.
Yep. Seeing the same thing in 5.2.0p1 with similar symptoms. In Windows, I don’t totally freeze up, but the editor feels like it’s running at about 2 hz. p4plugin.log shows continuous spamming fstat of the same file. The only way to make the editor usable is to set ‘work offline’ mode in the Perforce plugin settings.
OneThree, is your Perforce server on your LAN or do you connect to it over the internet? I tested 5.2.0p1 today from a computer connected to the same LAN as our Perforce server, and the editor was not performing as poorly. Perhaps this issue is magnified when response time to/from the Perforce server is longer?
Hi, Leon, just now saw your replies. Our P4 server is hosted by AWS, so it is remote. We’ve never had any speed issues with it, though, so I assume it’s a pretty fast connection.
We have the same problem with Plastic SCM, and we can’t update to 5.2.1 for our team too. I didn’t find where can I wote for the problem by case number
Hello everyone! I have seen some chatter on Twitter regarding this issue and wanted to provide you with an update. The issue is being worked on for the 5.3 release. The issue has been marked as “Necessary for shipping final release” which is a good thing!
Any chance of a 5.2 patch? The main project I’m working on I don’t think is ready for being updated to many of the changes in 5.3 (like multi-scene API stuff).
Our project is on 5.2.0f3, which is very buggy, and we really need a number of the 5.2.1+ animation fixes, not to mention the other fixes. We can’t downgrade our project, meaning we are now stuck with a bad, unstable version of Unity for over two months now. This impacts our schedule badly, not to mention how unpleasant it is to use 5.2.0f3 every day. It crashes constantly, there’s the “failed to move file” bug … hell, you can’t even sort your hierarchy alphabetically.
The fact that version control makes the editor unusable doesn’t get enough attention on this bug to have it fixed in less than 2+ months?
I understand its frustrating. </3 The good part is, its actively being worked on. They may backport it once it has a fix, but I can’t guarantee that so I don’t want you to count on it. I’ve added the issue to my personal watch list. If something changes, I’ll post here and update you.
It’s not just frustrating. It quite literally costs us time and money.
It’s one thing for there to be bugs with new features or overhauled systems, which may need several versions to get right. It’s quite another for bugs and regressions to appear in previously stable systems that projects depend on. Promptly addressing those categories of issues should be the absolute highest priority of a middleware vendor; they have a very direct, significant (negative) impact on both the cost of our projects and the eventual chances of success.
Bugs and regressions in stable systems need to be addressed asap in the same version line where the bugs were introduced, not in a hypothetical future version months away with an even more hypothetical (and opaque) possibility of being backported one day.
Short version: these sorts of bugs and regressions are the absolute worst sorts of bugs for an ongoing project. Please consider addressing this asap in 5.2.
Well-said, Leon. This puts our alpha deadline at risk.
Given that developers cannot roll back upgraded projects, it’s difficult to understand a set of priorities for the Unity team where breaking source control and trapping developers with an extremely buggy version of the editor for literally months would not call for an all-hands-on-deck approach to fixing this bug ASAP.
And here’s another question: why not roll back the change in 5.2.0p1 that caused this regression?
P4 was working flawlessly for us before that change; why can’t that change – which clearly was not tested enough – be rolled back until a real fix can be put in and properly tested? Perhaps rolling it back could even be exposed as an option in the editor’s version control settings so that teams who aren’t having this issue in 5.2.1 can keep rolling forward.
Anything is better than “You guys are screwed for two months.”
To be fair, P4 integration was not working 100% reliably for us before this; lots of edits were being missed by it, assets were often (incorrectly) appearing in the inspector as editable, only to eventually become grayed-out and the ‘check out’ button to appear, etc. So I definitely don’t blame anyone for trying to fix its problems. It’s just that the attempted fix resulted in an unusable editor, whereas the previous problems were annoying but not fatal.
