#rb none
#jira none
#rnx
#preflight 64258067b72410fc17a11f03
- The main goal was to prevent the GConfig from flushing to disk on shutdown as we do not want the tool to do that.
- We can do this by disabling the disk operations for GConfig or forcing the process to terminate, the latter of which we support in commandlets via the cmdline option '-fastexit'
[CL 24852905 by paul chipchase in ue5-main branch]
#rb trivial
#jira UE-151641
#rnx
#preflight 64103cb1c41a0a2a770c96a4
- Although we now relaunch the tool with the correct project path (if not supplied) this was not enough to allow us to load the projects config files and so set up the DDC and source control etc properly. My original testing was picking up hacks in the programs config file that was allowing it to work.
- FGenericPlatformMisc::ProjectDir has a bespoke path for standalone programs which means even if the uproject is on the cmdline it is ignored.
- We probably should look into a way for a project to mark itself as being "project aware" but for now we can make use of the project path override system to make sure it is set correctly, which will fix the problem for now.
[CL 24631824 by paul chipchase in ue5-main branch]
#rb Per.Larsson
#jira UE-170657, UE-160396
#rnx
#preflight 637c9232fa348e8480bdc7e2
- When the rehydration functionality was added it started to look like more functionality would be added to the tool than originally thought so I started to add the new functionality via a command system. This change now moves the older legacy functionality to the coommand system as well.
- Added a new FVirtualizeCommand which can accept package paths, directory paths, packagelist files or changelists as the input.
-- Unlike the legacy commands, virtualizing via changelist does not require the client spec to be provided on the commandline, although doing so will avoid several perforce commands and speed up the call. It is expected that people calling the tool on the commandline will probably opt to not supply a clientspec and let the tool workout which workspace a changelist is under, where as calls from other tools (such as P4VUtils) can provide it if already known to speed things up.
-- FVirtualizeLegacyChangeListCommand replicates the functionality of the old -Mode=Changelist command.
-- FVirtualizeLegacyPackageListCommand replicates the functionality of the old -Mode=Packagelist command.
-- The new command will only try to submit the results if a changelist was provided as the input and even then it will not do so by default. The tool now requires people to opt into submitting the changelist via the command line option -submit. NOTE: Other versions of the command maybe allow submission in the future but the virtualization process needs to be improved so that it can check out package files before this really makes sense.
- The rehydration command no longer requires a clientspec on the command line, it wasn't using the value anyway.
- Moved the source control code from the app code files to CommandBase. If we add more commands in the future we might want to factor this out to its own base class so commands can opt into source control functionality.
- In the future we should probably move the package -> project sorting code (FUnrealVirtualizationToolApp::TrySortFilesByProject) into the command base code as well.
[CL 23233456 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 626a5913631e64c0b9f23de3
- Some of our local structures, like FPLugin can get confused by the debugger with the version in the engine. Wrapping the tools code in the virtualization namespace helps keep the separation clear and stops the debugger from getting confused.
- Plus even though this is an UE program, I probably should've stuck to the new namespace rules anyway.
#ushell-cherrypick of 19955706 by paul.chipchase
[CL 19956237 by paul chipchase in ue5-main branch]
#rb PJ.Kack
#jira UE-143675
#rnx
#preflight 624c6a1814634fba5c7e3d71
### Rationale
- The new mode being added allows us to write a list of package file paths to be virtualized to a file on disk and then the file to be passed to the tool so that it knows what to virtualize. This new mode will then be used by P4VUtils.dll which is how we will run the virtualization process via p4v custom tools.
- We need this second mode because:
-- A workspace could have multiple projects in it, which means a user could try to virtualize a changelist with packages from more than one project.
-- Projects can be associated with different engine installations so the user could try to virtualize a changelist with packages using different engine installations, which in turn means that they need to be virtualized by different versions of the stand-alone tool.
-- This means we cannot rely on passing the CL number to the tool, install P4VUtils.dll will need to sort the package paths by engine installation, then pass those paths to the correct version of the tool.
-- The paths need to be written to a text file to be passed to the tool as the total length of path data can easily exceed the commandline max length limit if someone were to try and virtualize an entire project in one go for example.
- Note that the new mode does NOT submit the package files since there might be multiple calls to different versions of the stand-alone tool. In theory if all the packages are under one engine install (which is almost certainly going to be 99.999% of all submits) we could allow the tool to do the submit but that means we need to maintain two different code paths for the same operation.
- The existing mode (virtualize and submit a changelist) remains unchanged. It is not likely that an end user will ever use this mode, but it will make for a useful debugging tool in the future.
### Changes
- When the tool first starts we now print the log path to the user so that they can more easily find it. This might be something that we want to remove after a while, but during the initial release of the tool it should make getting good debug info back from users with problems somewhat easier.
- Some logging and error messages have had small updates made, to make the final output to the user more readable (based on the many many times this tool was run while testing). In some places additional logging has been added where I felt it was not clear to the user as to what was going on.
- Connecting to source control has been moved from the changelist parsing code to it's own method ::TryConnectToSourceControl since all modes will require it.
- The cmdline help output has been redone to support the multiple command line options we now have.
- Although we could infer the mode to run based on the commandline options, we require the users to explicitly state the mode via -Mode=XXX. In general the tool will be invoked from a gui so adding extra commands doesn't really affect the usability of the system and it makes things a bit clearer.
[CL 19665307 by paul chipchase in ue5-main branch]
#rb PJ.Kack
#jira UE-147055
#preflight 623c401ec3399da9533f1b29
### Features
- Designed to be a custom tool in P4V although it can be called manually.
- The submit works just like the in editor package submission process.
- If the changelist being submitted contains packages from multiple projects the tool can virtualize each project's packages in a separate pass.
### Limitations
- Currently no way to auto install, this has to be compiled and set up manually
- The tool is written in cpp and uses engine code, this is so we can share the in editor code for pushing payloads and work with any additional backend plugins that 3rd parties may have written.
- If a changelist does not contain any packages, or the packages are in a project that does not support virtualization there will be a small amount of overhead while the tool works out that nothing needs to be done.
[CL 19493529 by paul chipchase in ue5-main branch]
