- Only implemented for perforce source control at the moment.
- The source control operation FDownload file can be used just like any other command via ::Execute BUT it will also work with the new method ::TryToDownloadFileFromBackgroundThread which unlike ::Execute can be called from a background thread.
#rb Sebastien.Lussier
#rnx
* PerforceConnection
- Extend ::RunCommand to take an optional FSharedBuffer reference which can be used to return text/binary data downloaded as part of a perforce command
-- Ideally we would replace all of the out parameters with a single struct but that level of refactor would be better suited to its own submit.
- Removed the bool parameter for FP4ClientUser and replaced it with a set of flags instead
- Added a flag to allow FP4ClientUser to store data, either in binary or text format from a perforce command. Although in general this will be the result of a p4 print command.
* PerforceSourceControlCommand
- No longer assert if the command is not on the game thread if the operation indicates that it is safe to run on a background thread.
* PerforceSourceControlModule
- Register the 'DownloadFile' worker
* PerforceSourceControlOperations
- Add FPerforceDownloadFileWorker
* PerforceSourceControlProvider
- Adding implementation for ::TryToDownloadFileFromBackgroundThread.
-- This method is thread safe compared to the normal ::Execute call due to:
-- 1) This method does not accept any callbacks as the most common use of callbacks with ::Execute is to update the UI.
-- 2) This method does not add the command to any of the internal queues nor rely on Tick to process the command.
-- 3) The worker is invoked directly from the calling thread rather than as a background task.
--4) This method does not allow commands that modify the cached states as this would be very difficult to manage without rewriting how all commands are processed to make sure that they are only run one at a time and the results processed in order. NOTE that async commands can be issued from the game thread and can in theory be run in any order on the p4 server depending on how the background task processing works out with no certainty as to the order the results will be processed in. It is unlikely that we will process results out of order but not impossible, but this is a pre-exisiting issue with the current API, extending it to be fully multithreaded will just make it worse.
-- Note that we do not explicity check if the command supports being called from a background thread, as creating the command will check that anyway.
- Calling ::OutputCommandMessages is now thread safe. When called from the game thread it will issue it's output via FMessageLog as before but when called from a background thread we will use the UE_LOG macros instead. Marshalling all output in the same way is something we will need to solve when/if we make the entire API thread safe.
* PerforceControlSettings
- Improve thread safety when calling ::GetConnectionInfo
- If the password is stored in the UI then this is not thread safe but that feature is hidden at the moment due to being unsecure. I am unsure if we want to move the password to be stored in a member variable that can be accessed from any thread and only updated via the UI or not.
* SourceControlOperations
- Add new FDownloadFile operation.
- This can either download the file(s) to FSharedBuffers which can be accessed by calling ::GetFileData OR directly to a directory on disk if the target directory is supplied as part of the constructor.
* ISourceControlOperation
- Add a new base method CanBeCalledFromBackgroundThreads (false by default) which can be overriden by derived classes and return true to indicate that the operation can be run from a background thread. This is intended for use by FDownloadFile with the perforce source control provider in lieu and making the API fully thread safe.
#preflight 60a2290322cce000014243ae
#ROBOMERGE-SOURCE: CL 16346666 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v804-16311228)
[CL 16346668 by paul chipchase in ue5-release-engine-test branch]
* P4 SCC would give an "invalid syntax" error as the p4 command was ill formed
* Added early exits in USourceControlHelpers operations that take an array of files
#robomerge Release-5.0-EarlyAccess
#rb patrick.enfedaque
[CL 15727461 by Sebastien Lussier in ue5-main branch]
Changed the way we associate shelved files with their local filename to facilitate mapping (perforce operations)
Implemented what was needed on the SCC side to support diff against shelve
Improved way we display object names for deleted & shelved files
#rb sebastien.lussier
[CL 15356101 by julien lheureux in ue5-main branch]
- Added revert unchanged on changelists & files
- Added changelist parameter to the Execute method of ISourceControlProvider (& updated all derived classes)
- Fixed style problem in the Perforce settings dialog
#rb sebastien.lussier
[CL 15128504 by julien lheureux in ue5-main branch]
- FConfigCacheIni::ForPlatform(PlatformName) is the way to get the in-memory (won't write to disk) ini system for a different platform. Can pass it GEngineIni, etc for the filename ( FConfigCacheIni::ForPlatform("IOS")->GetString(....., GEngineIni); )
- GEngineIni and some others (the "stadnard, runtime ini files") are no longer filenames, but identifiers that will work with other platform Ini systems
- Modified "GETINI" console command to allow for a <Platform>@ prefix, to get another platform's ini value (using new multi-platform config) (GetIni [Platform@]IniFile:Section.SubSection Key)
#rb rolando.caloca
#fyi chris.gagnon,Sebastian.Nordgren
[CL 14473359 by Josh Adams in ue5-main branch]
#rnx
#rb none
#ROBOMERGE-SOURCE: CL 10869240 via CL 10869516 via CL 10869902
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870584 by ryan durand in Main branch]
