Release Notes
Public
8.0.16.3868: Dec 27 2019
New
Windows - Gluon: Incoming changes: The tool now converts pending changes into checkouts before calculating the incoming changes. This allows detecting the files in conflict with your current changes.
New
Unity 3D plugin - Gluon: Incoming changes: the 'Incoming changes" view is now complete! It allows you to solve file conflicts when there are new changes in conflict.
The "Resolve Conflicts..." context menu is now enabled. Now it is possible to resolve conflicts in assets individually.
An asset will be in "conflict" state when you have local changes in an asset, and somebody else created a new revision of the same asset in the repository on the same branch you are working on.
REMARK: Only available in Gluon mode!
Screenshots below:
This feature is experimental. You need to manually activate it by adding the following line to the client.conf configuration file.
On Windows, it is at %LocalAppData%\plastic4\client.conf:
<EnableGluonIncomingChanges>yes</EnableGluonIncomingChanges>
New
Command line client: Improved the cm find examples by adding some missing double-quotes to avoid errors when running the command on macOS and Linux.
Bug
All platforms - Plastic: The Incoming Changes operation sometimes left writable Xlinks as checked-out. This issue affected only Xlinks that pointed to a different changeset but without changes inside.
How did it happen? Let's assume that our workspace is loading the cs:5 with and we have a xlink at /doc.
1) Add the new file /doc/new.c and check it in (cs:6).
2) Remove the file /doc/new.c and check it in (cs:7).
3) Switch to the original changeset cs:5.
4) Run the Incoming Changes operation to update the workspace to cs:7. Then, the xlink /doc appears as checked-out without changes.
Not it is fixed!
Bug
All platforms - Plastic, Command line client: Fixed the order in some checkin steps that caused issues when a before-checkin trigger modified files in the workspace.
If this before-checkin trigger modified files in the workspace, these files were incorrectly detected as modified only AFTER the checkin.
This is because the workspace metadata got calculated before trigger execution, when it should be done just after it, in order to consider possible content changes.