Files

66 lines
1.9 KiB
C
Raw Permalink Normal View History

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
// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "Containers/Map.h"
#include "Containers/StringFwd.h"
#include "Containers/UnrealString.h"
class FString;
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
class SOURCECONTROL_API FSourceControlInitSettings
{
public:
enum class EBehavior
{
/** All existing settings will be overridden via the contents of FSourceControlInitSettings. Settings that are not found will be reset to default states */
OverrideAll,
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
/** Only the settings found in FSourceControlInitSettings will be overridden. Settings not found will be left with their current values. */
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
OverrideExisting,
};
enum class ECmdLineFlags : uint8
{
/** Do not read any settings from the commandline */
None,
/** Read all available settings from the commandline */
ReadAll
};
enum class EConfigBehavior : uint8
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
{
/** Can both read from, and save to the ini file*/
ReadWrite,
/** Will only read settings from the ini file, settings determined at runtime will not be saved to the ini file */
ReadOnly,
/** The settings will not be saved to the ini file, nor will they be read from the ini file */
None
};
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
FSourceControlInitSettings(EBehavior Behavior);
FSourceControlInitSettings(EBehavior Behavior, ECmdLineFlags CmdLineFlags);
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
~FSourceControlInitSettings() = default;
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
void SetConfigBehavior(EConfigBehavior Behavior);
bool CanWriteToConfigFile() const;
bool CanReadFromConfigFile() const;
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
void AddSetting(FStringView SettingName, FStringView SettingValue);
void OverrideSetting(FStringView SettingName, FString& InOutSettingValue);
bool HasOverrides() const;
bool IsOverridden(FStringView SettingName) const;
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
void SetCmdLineFlags(ECmdLineFlags Flags);
bool ShouldReadFromCmdLine() const;
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
private:
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
EBehavior OverrideBehavior = EBehavior::OverrideAll;
ECmdLineFlags CmdLineFlags = ECmdLineFlags::None;
EConfigBehavior ConfigBehavior = EConfigBehavior::ReadWrite;
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
TMap<FString, FString> Settings;
};