#rb Per.Larsson
#rnx
#jira UE-160619
#preflight 62f37c86b66d5d93133d67e3
- Based on work from Jess.Kube
### Virtualization
- The source control backend now takes an optional config option "ClientStream" which takes the name of the client stream to use.
- If a client stream is set then workspaces created for payload submission will use that and not provide a client-view mapping.
#ushell-cherrypick of 21195584 by Jess.Kube
### PerforceSourceControl
- Allow FCreateWorkspace to create workspaces with streams as well as classic workspaces cia FCreateWorkspace::SetStream.
- Add a method FCreateWorkspace::ClearClientViewMappings which will clear any client view mappings already added to the operation.
- If we detect that a FCreateWorkspace operation has both a stream set and client view mappings set then FPerforceCreateWorkspaceWorker will return an error. Perforce will allow us to creat a client spec with both entries, but will default to using the stream. Technically we could allow this too but it might cause unexpected behaviour to the caller. It is better to give a clear error and fail the workspace creation.
[CL 21316756 by paul chipchase in ue5-main branch]
Headers are updated to contain any missing #includes needed to compile and #includes are sorted. Nothing is removed.
#ushell-cherrypick of 21064294 by bryan.sefcik
#jira
#preflight 62d5c2111062f2e63015e598
#ROBOMERGE-OWNER: bryan.sefcik
#ROBOMERGE-AUTHOR: bryan.sefcik
#ROBOMERGE-SOURCE: CL 21155249 via CL 21158121 via CL 21161259
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v972-20964824)
[CL 21182053 by bryan sefcik in ue5-main branch]
#rb trivial
#rnx
#preflight 62d15f427e1c26dcd715699c
- Now that the IVirtualizationSystem interface supports both virtualization and rehydration of package files, it seems pointless to keep a delegate that occurs on pre-submit, rather than just calling the system we really want to call directly.
- Deprecating the public methods accessing the delegate from ISourceControlModule should prevent licensees from trying to use it. The delegate was added in 5.0 so even though it is unlikely to have been used by anyone we need to go through the deprecation steps to remove it.
-- This leaves the calling code a little more complicated than I'd like, but cannot be avoided.
[CL 21109464 by paul chipchase in ue5-main branch]
* Contains some selected back outs from other cls that included config context dependent changes, though it's limited to only backing out broken parts as much as possible to minimize surface area.
[Backout] - CL20029182
[FYI] josh.adams
Original CL Desc
-----------------------------------------------------------------
- Adding FConfigContext which is used to repalce LoadExternalIniFile, LoadLocalIniFile, etc, as well as have localized data for all configs read on a thread (like the other platform configs loaded in the editor)
- The Load*IniFile functions will create a Context, but eventually those APIs will go away and the Context will be the only way to load ini files
- Simplified some of the ini loading code, like removing the HierarchyCache (it wasn't helping editor load times, and added much complexity, and was not thread-safe, and it shouldn't actually be helpful because all the calls to Load*IniFile should eventually be replaced with either GConfig or FCOnfigCacheIni::ForPlatform(), which won't need to re-read in files
- Ini reading time actually went down due to the simplification, including Cache removal
- Left in old code for now behing a #define (USE_CONTEXT) in case something goes wrong
- Added in VERIFY_CONTEXT mode which I used to run original and Context modes and compare (including preflighting builds) (I also added a Compare function that we may want to keep around to use for future debugging)
- Added a separate set of config layers for plugins which speeds up plugin parsing, but also will fix the issue with BaseEngine.ini vs DefaultEngine.ini in Engine vs Project plugins (this shows how Contexts can bring useful information down into the guts - however a later change will enable it)
- Once this is all seen to be working, I will clean up the non-Context functions, and some globals vs static members, etc
#rb paul.chipchase
#preflight 62716c1c5e6ce673f452005a
#ROBOMERGE-AUTHOR: josh.adams
#ROBOMERGE-SOURCE: CL 20029165 via CL 20029180 via CL 20905839 via CL 20905880
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v971-20777995)
[CL 20908094 by mic rooney in ue5-main branch]
Updates to source control helpers that:
- allow for reverting files marked for delete
- return success on a successful 'mark for delete'
#rb YiLiang.Siew
#rnx
#preflight 629fca23617cbe81d33de34d
#ROBOMERGE-AUTHOR: stanley.hayes
#ROBOMERGE-SOURCE: CL 20569168 via CL 20569170 via CL 20569172 via CL 20569174 via CL 20569176
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v954-20466795)
[CL 20570262 by stanley hayes in ue5-main branch]
#rb trivial
#rnx
#preflight 622f580e344901ad192a0cdd
- Fix incorrect spelling in the method name.
- Oddly enough this was spelt correctly for both the member and in the comments.
[CL 19373079 by paul chipchase in ue5-main branch]
#rb Patrick.Laflamme
#jira UE-145721
#rnx
#preflight 622f0358752729a2ad448e16
- The problem we have is if a p4 depot path is used when requesting filestates (to see if the file exists in p4 for example) it will be treated as a networkpath due to it starting with // so calling the filesystem to check if it is a directory or not can get very expensive.
- Other operations just check the end of the path for '/' or '\' which is what this operation used to do, but that was changed at some point to check the file system, presumably to fix another problem and as we don't really know how 3rd party code is using this system we cannot just change the behavior without risking breaking existing code bases.
- This fix allows the caller to opt in to the old behavior of just checking the end of the path to determine if it is a directory or not.
- This fix is not very good, future work for a better fix will be tracked in the attached jira.
[CL 19371141 by paul chipchase in ue5-main branch]
#rb Luc.Eygasier, Sebastien.Lussier
#rnx
#preflight 622895d331133a23da78a4ca
### Misc
- FPerforceSourceControlRevision, FPerforceConnection and FPerforceSourceControlLabel now own a reference to their FPerforceSourceControlProvider and accesses the connection settings from that rather than via the module singleton.
- FPerforceSourceControlCommand now accesses the connection settings by finding the FPerforceSourceControlProvider that the given IPerforceSourceControlWorker references.
- FPerforceSourceControlProvider now owns it's own FPerforceSourceControlSettings rather than accessing a shared one owned by the module.
- Marked a number of derived classes as final.
### FPerforceConnection
- ::EnsureValidConnection can now work without a valid client (although most commands will require a client to run, things like p4 print does not).
-- Due to this change we might not catch cases where the the system cannot connect to source control as the user is not logged in as this would get caught when we checked the workspace by calling ::TestConnection.
-- To get around this ::EnsureValidConnection will now call "p4 login -s" via the newly added TestLoginConnection.
- Renamed ::TestConnection to ::TestClientConnection as we are really testing the connection to the specified workspace.
- There does seem to be some inconsistency in the logging, depending how a perforce source control provider first creates its connection as in some cases FPerforceConnection::EnsureValidConnection gets called first and in other cases FPerforceConnection::EstablishConnection is called. We should unify these paths but this change list is already so large I am opting to postpone this to it's own work item.
### FPerforceSourceControlModule
- Removed all of the singleton style accessors so that classes inside of the module can no longer assume that there is only one FPerforceSourceControlProvider. Updated the documentation to match.
- Since there is no reason for classes in the module to need to access FPerforceSourceControlModule, ::Get has been removed
- The responsibility to register all of the worker creation delegates has been moved to IPerforceSourceControlWorker so that all source control providers can share them.
- ::GetProvider has been removed, if a class inside the module needs access to a provider then a reference to it's provider will be given to it at construction time.
- ::SetLastError, ::AccessSettings and ::SaveSettings are now called directly on FPerforceSourceControlSettings
### FPerforceSourceControlSettings
- This class now takes the name of the system that owns it as a parameter in the constructor
-- The name will be used to identify where to store the settings in the config file, unless the name is blank in which case the pre-existing default location will be used.
- This will allow for multiple source control providers to store their connection info.
### SPerforceSourceControlSettings
- Moved FGetWorkspaces from SPerforceSourceControlSettings.h to its own header file to reduce the number of places that need to include the slate headers.
- Move the fwd declares to the top of the header base don recent coding standards discussions.
- Instead of accessing the source control provider via FPerforceSourceControlModule the dialog is now given a pointer to one when constructed.
-- This pointer is assumed to always be valid and should be a reference if the slate system supported it.
### PerforceSourceControlOperations
- IPerforceSourceControlWorker now takes a reference to the owning FPerforceSourceControlProvider in it's constructor. All derived workers have been updated to this.
- Moved the registering of worker creation delegates from the module cpp to a new static method IPerforceSourceControlWorker::RegisterWorkers
-- This should make it easier to find when adding a new worker and allows source control providers to share the same map of delegates rather than duplicating it.
-- This means we also need a new static method IPerforceSourceControlWorker::CreateWorker for instantiating new workers based on the given name.
### FSourceControlInitSettings
- This is a new class that is used to set up a newly created source control provider.
- The settings are expected to be given in the same way you would override settings via the cmdline. The existing perforce cmdline code has been updated to use this class.
- This still has the downside that the calling code needs to know the type of source control provider, but I don't really see a good way around this unless we refactor the entire API to be feature based.
[CL 19318801 by paul chipchase in ue5-main branch]
#rb scott.nelson
[FYI] luc.eygasier
#preflight 62055a9369224cb0d87518ca
#ROBOMERGE-OWNER: richard.malo
#ROBOMERGE-AUTHOR: richard.malo
#ROBOMERGE-SOURCE: CL 18943053 via CL 18944261 via CL 18944332 via CL 18944374 via CL 18946678 via CL 18946778
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v917-18934589)
[CL 18946785 by richard malo in ue5-main branch]
* Introduces a new 'GetFileList' operation
* Adds "keep checked out" option to other operations
#rb Luc.Eygasier
#preflight 620598920c64e1822f4849a8
[CL 18946159 by Mike Beach in ue5-main branch]
