Search Issue Tracker
Duplicate
Votes
0
Found in
2017.4.0f1
2018.3.0a1
2018.4.0f1
2019.1.0a1
2019.1.4f1
2019.2.0a1
2019.3.0a1
Issue ID
1159214
Regression
No
[Perforce] File status fails to update and performance is slowed after changing the Workspace to that of the same root directory
How to reproduce:
1. Make sure you have 2 separate workspaces with the same root directory in Perforce (Example: "worksspace1" linking to folder "1159214"; worksspace2 linking to the same folder "1159214")
2. Create a new project in the root folder and set it up to use one of the workspaces (Example: worksspace1)
3. Change the workspace to the different, same root directory one (Example: worksspace2)
4. Observe the file status in the Project Window and the poor performance if tested on some versions
Expected result: the file status is updated without issues and the performance isn't slowed down
Actual result: the file status is shown as "updating" forever and the performance is severely slowed on some versions
Reproduced in: 2019.3.0a5, 2019.2.0b5, 2019.1.5f1, 2018.4.1f1, 2017.4.28f1
Versions where performance is impacted: 2019.2.0b5, 2019.1.5f1, 2018.4.1f1
Versions where performance is not impacted but still reproduce the status issue: 2019.3.0a5, 2017.4.28f1
Note: In order to fix the performance issue the user has to either delete the Library folder where the Perforce credentials are stored or change the workspace back to the original one.
-
Resolution Note (2019.3.X):
This issue originates from the Perforce plugin mishandling the status message for files ignored in a particular manner (i.e. files that have a status of "file(s) not in client view").
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
This is a duplicate of issue #1148796