Release Notes

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.