Release Notes

Public

8.0.16.3685: Oct 30 2019

New

Windows - Plastic: Incoming Changes, the new way to work on a single branch, is finally here.

The feature is so important that we wrote a blogpost to explain it:

Incoming Changes feature explained

How to enable it:

Write this in your client.conf:

<EnableIncomingChanges>yes</EnableIncomingChanges>

New

Windows - Plastic: We are making a series of improvements to the single branch working workflow.

When you are working in a single branch with other people, it is common to find they have checked in new changes.

When this happens, Plastic will notify you on the top-right area of the window.

* Scenario 1. You have no pending changes and new changesets from other users appear. Plastic will show you a green notification in order to allow you to see the changes in the Incoming Changes view, and update to them.

* Scenario 2. You have pending changes. New changesets from other users appear, but they don't affect any of the files you have changed. Plastic again will show you a green notification in order to allow you to see the changes in the Incoming Changes view, and update to them.

* Scenario 3. You have pending changes. New changesets from other users appear, and there are changes in files that you have also changed. In this case you need a merge. Plastic will show you a red notification in order to allow you to see the conflicts in the Incoming Changes view, and resolve them.

This is how the Scenarios 1 and 2 look like:

ScreenshotScreenshot

And this is how the Scenario 3 looks like:

ScreenshotScreenshot

You can see it working here:

ScreenshotScreenshot

This feature is still experimental. You need to manually activate it, adding the following line in the client.conf configuration file, that is located at %AppData%Localplastic4 folder:

<EnableIncomingChanges>yes</EnableIncomingChanges>

New

All platforms - Plastic, Command line client: the merge now checks for locked files and directories before applying changes.

Files and directories locked by third-party applications is a very common source of issues during a merge (Unreal users might be well aware of this!). Plastic might try to remove a file or a directory from your workspace, but because there is an application locking it, the operation fails - potentially leaving the workspace in an inconsistent state that is not obvious to recover.

We have just fixed this by checking that the files and directories involved in a merge are not locked before applying a merge (and this affects the upcoming Incoming Changes that will be the default way to update changes in a workspace when working on a single branch).

= How the detection looks like =

Suppose Notepad.exe is locking a file you are trying to merge. You'll get a message that looks like this:

The operation cannot start because some files or directories are locked by another program. Please close the program and try again.
    e:/wks/actioncable/doc/cord/de_win.c (used by Notepad, notepad.exe, 4856)

And this is the message you get if what's locked is a directory:

The operation cannot start because some files or directories are locked by another program. Please close the program and try again.
    e:/wks/actioncable/doc/cord

= Going under the hood =

How do we detect locked files and directories on each platform?

* Windows and macOS: we open each file involved and try to move each directory involved to a temporary location.

* Linux: nothing, since Linux FS are quite friendly when it comes to applying changes to disk, so we don't have to worry about aborted operations by locked files or directories.

= Performance impact =

Since we now check every file involved in a merge prior to really combine the files and apply changes, we can expect a performance impact.

These are some numbers we grabbed so you can get an idea: checking if 50000 files are locked by another program takes 3 seconds.

New

macOS, Linux - Plastic: Say hello to the new Attributes View! It will allow you to list and manage the existing attributes in a repository. You'll be able to create new attributes, edit existing ones or simply delete them. This view was really necessary since we introduced the ability to define a list of default values in the attribute comments!

Here goes in macOS:

ScreenshotScreenshot

This is how it looks like on Linux:

ScreenshotScreenshot

We also fixed attribute definition in macOS with multiple predefined values: before if you defined default:one, two, "and three" the third value didn't show up in combos as "and three" but as two values. It is now fixed.

New

All platforms - Plastic, Gluon: A lot of users have found the contextual help in the Plastic and Gluon UIs very useful. But for our more advanced users the help panel was getting in the way without providing any real benefit. Now, each help item will only be shown at most once a day, and we will only show more help than that when we detect you are having difficulty with the tool. Also, if the help panel opened automatically, rather than by pressing the help button, it will hide itself out of the way again after a few minutes.

By the way, if you select "Got it, don't show me again" on the help panel, that help item won't appear ever again!

New

All platforms - Proxy: Added support for Plastic Protocol.

The Plastic Proxy (a.k.a. cache server) now can handle requests using Plastic Protocol instead of just "remoting".

The Proxy was already reaching remote servers using Plastic Proto, but it handled requests from clients using *only* remoting.

Plastic Proto is a new binary protocol we developed a few years ago, and remoting is the older protocol we used for years, that is slightly less efficient, that's why our goal is to stick to Plastic Proto and deprecate remoting later on this year.

Bug

Windows - Plastic: A few releases earlier we introduced new color filters for the Branch Explorer. But there was a bug on Windows! As you know, when there is more than one label in a changeset, we draw a split crown. When searching, all of the pieces of the crown get colored even if only one of the labels matches the search - however, none of the pieces got colored if the filter matched another label different than the first one. That's fixed now. Thanks to forum user Wolfram for noticing and reporting this!

Bug

All platforms - server: We detected some scenarios where the 'mergeto' endpoint of the server REST API failed. This happened if the merge contained a multi-file conflict and changes under an Xlink, too. As a side note, the main consumers of this endpoint are our mergebots. Now it's fixed.