Release Notes
11.0.16.7709: Jan 12 2023
Windows - PlasticFS: Upgrade to WinFSP 2023 Beta1
Among other changes, the next version of WinFSP does not require to reboot for upgrading.
You can find the WinFSP release notes in https://github.com/winfsp/winfsp/releases.
Windows - PlasticFS: Junction support for dynamic workspaces
We added support for junctions to PlasticFS! Tools that create temporary junctions on disk can now run on dynamic workspaces.
Before:
> mklink /J assets ..\..\game_tree\assets Local NTFS volumes are required to complete the operation
After:
> mklink /J assets ..\..\game_tree\assets >
In PlasticFS, junctions have the same limitations and capabilities that symlinks have, with the following exceptions:
* Junctions, they can only be used with directories. The flip side is that, unlike symlinks, junctions always have the right type.
* Junctions only support absolute paths.
* Plastic itself does not distinguish between "junctions" and "symlinks". Adding a junction to source control will eventually replace it with a symlink.
== REQUIREMENTS ==
Besides PlasticFS, you might want to enable symlinks in the GUI and the command-line interface.
To do so, add the following to your client.conf:
<EnableSymlinkSupportOnWindows>yes</EnableSymlinkSupportOnWindows>
== LIMITATIONS ==
1) This feature is in an early stage of development, so you can expect minor bugs to happen.
2) Currently, junctions are not allowed to point to the dynamic workspace directory nor anything outside it.
All clients: Incoming Changes only checks-out local changes involved in conflicts.
Before, the Incoming Changes & merge operations applied all the local changes in the workspace before running the operation. It didn't matter whether these local changes were in conflict with the changes to update/merge or not.
This could end up locking exclusively some files that were only locally modified (unrelated to the merge/update) and preventing other users to modify those files due to an undesired lock.
Now, only the local changes that are in conflict with the server changes to update/merge are applied in the workspace.
This new behavior applies to PlasticX, Plastic and the command line client (it's not available or partial/Gluon workspaces yet).
All platforms - PlasticX, Command-Line Client: Triggers are not accepting URIs on Windows servers
Due to the possibility of working cross-platform, sometimes Plastic is performing paths correction to fit the different OS's syntax. Therefore, anything that might be considered as a path can be altered by replacing slashes with backslashes on Windows. That was affecting the trigger commands, which can receive arguments. Usually, these arguments are expected to be paths, many times the executable itself, but it is also possible to use Internet addresses and endpoints. These addresses were being altered when parsing the command arguments (replacing the slash). That was leading to unexecutable triggers on Windows servers.
Now it is fixed and it will be possible to create triggers receiving valid URIs as arguments.
For instance:
cm tr mk before-update TryToLoginTrigger "curl -X POST http://localhost:8080/login ./secret.key" --server=localhost:8084
When creating the command on a Windows machine, it will fix the "./secret.key" path to convert it to ".\\secret.key" but the localhost endpoint will remain the same.
This allows new possibilities of interaction through triggers on Windows machines.
NOTE: to be able to distinguish between local paths and external URI, it is advisable to use absolute URIs.
A known limitation for this would be the following syntax:
cm tr mk before-update UnityTrigger "curl -X POST unity.com/amazing" --server=localhost:8084
Under the hood, Plastic will modify the "unity.com/amazing" and use the "unity.com\\amazing" endpoint instead, because the literal complies with the local path formation rules.
The way to avoid the issue would be to use the absolute URI referring to the same endpoint: "https://unity.com/amazing", which will remain unaltered.
Command-line client: status command now gives changed/unchanged info for checkouts
Unlike in the GUIs, the command line was only able to show an item as either checked-out or changed, but not both at once. This made hard to tell if a file was actually modified or not:
> cm status --noheader Changed Status Size Last Modified Path Checked-out 10 bytes 12 minutes ago checked-out-CHANGED.txt Checked-out 11 bytes 13 minutes ago checked-out-unchanged.txt > cm status --noheader --compact Modified items (CH = changed, CO = checked-out, CP = copied (new), RP = replaced) CO checked-out-CHANGED.txt CO checked-out-unchanged.txt
Now, additional detail is given when changes are found:
> cm status --noheader Changed Status Size Last Modified Path Checked-out (changed) 12 bytes 1 minute ago checked-out-CHANGED.txt Checked-out (unchanged) 11 bytes 21 seconds ago checked-out-unchanged.txt
The "--compact", "--xml" and "--machinereadable" options don't display these details by default. It is so to not break existing integrations/automations. You need to combine them with the "--iscochanged" option to see the additional information.
> cm status --noheaders --noheader --compact Modified items (CH = changed, CO = checked-out, CP = copied (new), RP = replaced) CO checked-out-CHANGED.txt CO checked-out-unchanged.txt > cm status --noheaders --noheader --compact --iscochanged CO+CH checked-out-CHANGED.txt CO checked-out-unchanged.txt
Note that this information is only provided when the status command is searching for changed items (see the --changed option in --help for details). For instance, in case you only need to find whether items are or not checked-out, you can filter the search by using the --checkout option. That way, those details will be omitted as before.
Server: Incoming Changes failed with path permissions and a cloaked rules.
From 11.0.16.7656, the Incoming Changes failed and didn't appear when certain conditions were met: 1) there were set path permissions, 2) no cloaked.conf in the client and 3) a cloaked.conf loaded on the head tree of the branch (it contains a /cloaked.conf file). Now, it's fixed.
All platforms - GluonX: Null exception on clicking the Get Plastic link button in Checkin view
We fixed it to don't show this button in the details panel for the Checkin View because it is only available for the Explore workspace view.