Release Notes

Public

Release 7.0.16.2256

May 28 2018
New

Configuration to merge Unity files on Windows: Added "SmartMerge" support out-of-the-box for new installations:

* .prefab and .unity files will use "UnityYAMLMerge.exe" (a.k.a "SmartMerge") to merge both contributor contents on a file during a merge

* If SmartMerge requires manual conflict resolution, it will fallback to regular PlasticSCM text mergetool.

* .meta files will use Plastic SCM regular text mergetool too.

REMARKS:

* The Unity SmartMerge configuration is hard-coded in Plastic SCM configuration. We assume that, if you are managing .prefab and .unity files, you will likely have Unity & SmartMerge installed

* Attempting to merge a .prefab or .unity file will throw an error if SmartMerge application does not exist in expected install path:

 %ProgramFiles%UnityEditordataToolsUnityYAMLMerge.exe

* If that happens, you will have to manually edit the SmartMerge path in Plastic SCM Merge Tool preferences.

* More info about Unity Smart Merge can be found here

New

The branch, label, attribute and repository name cannot longer include the character \r nor the character \n on it.

New

SemanticSCM: Now, the 'skip format changes' and 'comparison method' options are updated according to the option selected by the user (e.g: if the user checks the 'skip format changes' option, the 'comparison method' is updated with the "Ignore EOL and whitespaces" value and vice versa).

New

Gluon: We redesigned the set of actions you're allowed to perform during long checkin operations:

* The items tree will be locked in order to prevent checkboxes from being toggled (windows, linux, mac)

* The Switch button will remain disabled during the checkin operation (windows, linux, mac)

* The auto-refresh feature will be disabled while the checkin operation is still running (only windows)

* We fixed the message displayed when there's an operation running (only windows)

New

Modified lock strategy during merge.

Now files that are copied to the workspace during merge but are not in conflict will not be checked out and hence locked.

As a result, merges from the head of the branch can be completed even if one of the files to copy from head is locked by another user.

== Problem ==

This fix is relevant for teams where users do locking and merging no a single branch on the same repo. It won't be a problem if developers use branches or if binaries and code (typically art and code in games) are on separated repos.

== Scenario description ==

* Jim touches CarBehavior.cs.

* Meanwhile Tony checked in CarBehavior.cs.

* Beth checkins Car.prefab and locks it again to continue working.

* Now Jim wants to checkin CarBehavior.cs but requires a merge because Tony modified it too.

* The merge requires Car.prefab to be downloaded, and the previous lock strategy tried to lock it. The merge couldn't proceed because the file was already locked.

== When was it modified previously ==

We modified the strategy back in 7.0.16.1857 (Dec 18th 2017) and this has created several issues with locks and merges.

New

Gluon can now merge files!

We just added merge capabilities to Gluon. So, now when files are in conflict during checkin, Gluon will launch the configured merge tool (same tool configured for regular Plastic) and help you solve the conflicts.

It works on the 3 platforms.

Bug

Mac OS GUI: the application crashed when the browse repository view was opened and closed several times. Fixed.

Internal and public releases

The Plastic SCM development team works in short iterations delivering frequent releases.Our goal is to have at least one new release every week, with new functionalities, bug fixes and performance tweaks.

Every 'weekly' release is not published to our customers, but we like to detail each of them in the release notes so users can easily follow what we achieved on every short iteration.

The releases marked with the word "public" are the ones we do publish on the website. The ones marked as "internal" are the releases we create in-house to keep the project moving week after week.

Version numbering

Starting in Plastic SCM 4.0 the version numbering schema has been modified:

  • major.minor.compatibility.buildnumber

  • Sample: 5.0.44.511 means:
    • 5 -> major release number
    • 0 -> minor release number
    • 44 -> compatibility -> all clients and servers with "44" in the compat number are compatible, even if the build number changes
    • 511 -> internal build number