#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]
