2 Commits

Author	SHA1	Message	Date
paul chipchase	623ba6cc9e	The source control settings for the VA source control connection are no longer saved to a local ini file. ... #rb Per.Larsson #jira UE-163834 #rnx #preflight 632d98e4b4515b7e221654ec ### Virtualization - At the moment there is no way in the editor UX to change the source control settings for the source control backend, so what ever settings are found in the global environment would be applied when the editor is first run and then saved to a config file under the <saved> directory. From this point onwards those settings would always be used when setting up the source control backend. If the settings were wrong, the first time that the editor was started, then we'd continue to use the incorrect settings even if the global enviroment was fixed. Making the backend work at that point would require that the user know about the local ini file and change the settings there. - We cannot fix this by just ignoring the ini file as it has been requested that users can add their settings there in case they want to customize things, so we just need to avoid saving to it. - Added documentation to the source control backends header file on how to set up the ini file if needed. ### Perforce - FSourceControlInitSettings now accepts EConfigBehavior which describes how we want the source control provider to deal with its settings with regards to the ini file. - Note that EConfigBehavior is not a bitfield as we do not wish to support only writing to the ini file, there is no point if it cannot be read from. - When the source control provider is creatred we pass on the into from EConfigBehavior to the FPerforceSourceControlSettings to enable/disable saving and loading. [CL 22163769 by paul chipchase in ue5-main branch]	2022-09-23 20:05:59 -04:00
paul chipchase	c08d860e2e	Allow additional source control providers to be created so that specialized subsystems can maintain their own separate connection without interrupting the normal editor workflows. ... #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]	2022-03-09 07:10:46 -05:00