#rb Sebastian.Nordgren
#rnx
#jira UE-156436
#preflight 62c287f9a3568e30664eb94f
### VA Standalone Tool
- We now plan to add much more functionality to the tool than just virtualizing and submitting changelists, so to make this easier I am moving the tool towards a design where it should be fairly easy to add new functionality.
- Added FCommand, which is a base class for adding new functionality, simple derive from FCommand and hook it up at the appropriate locations.
-- In the future it should be possible for new command types to automatically register themselves to be initiated from the command line. There should be no need to edit UnrealVirtualizationToolApp to add a new command but this will be done as an additional work item.
-- At the moment FCommand comes with a number of utility methods to call that cover some common source control commands.
-- The original functionality has not yet been moved to the command system and so the code is a little bit weird at the moment. Updating older code to the new system will be done as an additional work item.
- FProject/FPlugin have been moved to their own code files.
### Rehydrate Command
- The rehydrate command will take a number of packages, check them out of source control and then attempt to virtualize them.
- At the moment the chekout logic is fairly basic, we just check out every package supplied, we don't check if the package is virtualized or not yet. This can be improved in additional work items. Ideally by the end of command the only packages that we have checked out should also be rehydrated.
- At the moment the command can either take a path of a specific package, a path of a directory to find packages in, or a changelist containing packages that should be rehydrated.
- A cleint spec (workspace) can optionally be provided, but if not supplied we will attempt to find a client spec for which to check out the packages.
- Currently we will check out the packages to the default change list.
### Rehydrate process
- Added the rehydration process in it's own code files in the virtualization module. Like the virtualization process this is exposed in a public header file and no via the Core interface which means it is very specific to our module/implementation.
- The process expects that the caller will have checked out any required packages from source control. It will treat being unable to update a package file as an error.
- Added PackageUtils.h/.cpp and moved some of the generic code from the virtualization process code there so that it can be shared by the rehydration process.
### Misc
Moving away from the using things like FPackagePath as that requires that the correct mount points have been registered for a project and at the moment (with the flakiness of FConfig*) it seems that the best idea would be to prefer absolute file paths where possible.
[CL 20982284 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 628ccc455665463c21036888
- The main change is that if we do not find the project file relative to the first /content/ directory we will keep looking up the path to see if we can find additional /content/ directories.
- All log messages have been changed to warnings for consistency.
[CL 20346906 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 626b99f95c220f34acd748f6
- We were printing out the packagelist file path both when it was found as a command line arg and when parsing it, we now only print it when it is found as an arg
- Any log section that indicates it could be slow has had "..." appended to it to show the user that this is expected
-- Any log message in a section like this is now tab indented to make the association easy for the user to see.
[CL 19976012 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 626b928953253f874b90a23a
- We now connect to perforce if either a) we need to parse a given changelist to find the package files b) we need to submit the given changelist
- This means we won't connect to perforce at all when running with the cmdline '-Mode=PackageList' saving a few seconds (although if the virtualization system is using the source control backend, then a connection will be made there anyway)
[CL 19975945 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 626a99f3a5009ff191af09db
- The log message stating that the tool is now trying to submit a changelist was accidently set to 'Error' when it should be 'Display'
[CL 19961053 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]
