Files
UnrealEngineUWP/Engine/Plugins/Developer/PerforceSourceControl
paul chipchase d8503fff99 Running FGetFile while the perforce source control provider is active will no longer incorrectly mark the connection as dropped, preventing future commands from being run.
#rb Wouter.Burgers
#rnx

### Bug Fix
- In CL 24941987 FPerforceGetFileWorker::Execute was modified to remove the perforce connection being created as that connection was not used and FPerforceSourceControlRevision::Get would create a second connection to be used.
- Removing this connection has an unintended knock on effect in that the command passed to the worker was never marked as having a successful server connection. So next tick the source control provider would check the now completed command, see that the connection was not a success (even though the command returned a success) and mark the connection to the server as broken, preventing future commands from working.
- Over the last year or so we have tried to move the code away from these sort of non-obvious side effects but there is a lot of work to do still.
- For now it is safest to add the connection back to FPerforceGetFileWorker::Execute but also add an overload to FPerforceSourceControlRevision::Get that allows us to pass in the connection to be used, to avoid the original problem of creating two connections as connection creation is super slow and can be costly on the server.

### Additional Changes
- There was no reason to allocate the FPerforceSourceControlRevision in FPerforceGetFileWorker::Execute on the heap as it is used immediately then deleted. We might as well just create it on the stack.
- Changed some code logic to early out rather than having long conditional scopes.
- The input parameters for FGetFile are still a bit odd (no revision == #0, revision -1 == #head etc) but leaving that alone for now until we merge FGetFile and FDownloadFiles to eliminate the duplicate code functionality.

[CL 25867524 by paul chipchase in ue5-main branch]
2023-06-08 06:56:20 -04:00
..