Release Notes

Public

8.0.16.3859: Dec 20 2019

New

macOS - Plastic: The Code Review is finally available for macOS users!

We still have some things to implement, but you can start using it in your day to day.

You can access the code reviews from the sidebar.

Creating a code review is as easy as one-two-three. Just right click a branch, and select "New Code Review for this branch...". It also works for changesets, both from the Branch Explorer and from the Query views.

Once you open a new code review, you will see the following warning in the window:

It reminds you that the feature is still in beta (so be patient if you find some rough edges!). Clicking the link redirects you to a blogpost where we keep an updated list of the Code Review restrictions in macOS - a list we hope to shorten fast.

Learn all about Code Reviews for macOS here: Code Review now available for macOS.

New

All platforms - Plastic: A few releases back, we changed the default path of the Branch Explorer configuration file. It is now inside the .plastic directory, and it's name is plastic.branchexplorer (to match the naming of the rest of the files already there).

Now that the Branch Explorer configuration exists per workspace (instead of a unique file affecting all the workspaces in your machine), it is time for the global Branch Explorer configuration to be per repository server, and then per repository (instead of a unique file affecting all the workspaces in your machine!)

You see, until now the global BrEx configuration gets loaded only from the allrepos directory in your default repository server's Global Configuration. This made sense when said configuration affected all of your workspaces - you wouldn't want BrEx configuration coming from other repository server different than your default one (what a mess!) But now it is natural (and possible) to design global configuration per repository.

Bear in mind that in the global BrEx configuration you can only define Filters and Conditional format rules. These filters and format rules are merged with your local ones when the global configuration gets downloaded. You can't still distinguish the origin of each rule though (global or local configuration), so there is still room for improvement.

The search path for the Global BrEx configuration is as follows (to support the legacy location, and the new possibilities). The first configuration file found is the one that will merge with the local one.

let SpecificRepo         be the Repository your current workspace is pointing to.
let SpecificRepServer    be the Repository Server that hosts SpecificRepo.
let DefaultRepServer     be the Repository Server you have configured in client.conf.

Search path goes as follows (to support legacy behavior too!):
  1) globalconfig/SpecificRepServer/SpecificRepo     [new]
  2) globalconfig/SpecificRepServer/allrepos         [new]
  3) globalconfig/DefaultRepServer/allrepos          [legacy]

But we also support the following file names for Branch Explorer
configuration:
   - branchexplorer.cfg          [legacy Windows]
   - branchexplorer.conf         [legacy Linux & macOS)
   - plastic.branchexplorer      [new, all platforms]
   
The search path goes as follows:
   1) New filename, new path
   2) Legacy filename, new path
   3) Legacy filename, legacy path

With this, the search path is as follows:
   1.1) globalconfig/SpecificRepServer/SpecificRepo/plastic.branchexplorer
   1.2) globalconfig/SpecificRepServer/SpecificRepo/branchexplorer.conf
   1.3) globalconfig/SpecificRepServer/SpecificRepo/branchexplorer.cfg
   2.1) globalconfig/SpecificRepServer/allrepos/plastic.branchexplorer
   2.2) globalconfig/SpecificRepServer/allrepos/branchexplorer.conf
   2.3) globalconfig/SpecificRepServer/allrepos/branchexplorer.cfg
   3.1) globalconfig/DefaultRepServer/allrepos/plastic.branchexplorer
   3.2) globalconfig/DefaultRepServer/allrepos/branchexplorer.conf
   3.3) globalconfig/DefaultRepServer/allrepos/branchexplorer.cfg

Until this release, the client looked for the file only in 3.2 and then 3.3.

We recommend using the new name plastic.branchexplorer!

With an specific example, imagine that your current workspace is pointing to awesomeproject@remoteserver:9095, but your client is configured against localhost:8087. When opening the workspace in a GUI, the Branch Explorer global configuration file search path will be as follows:

globalconfig/remoteserver_9095/awesomeproject/plastic.branchexplorer
globalconfig/remoteserver_9095/awesomeproject/branchexplorer.conf
globalconfig/remoteserver_9095/awesomeproject/branchexplorer.cfg
globalconfig/remoteserver_9095/allrepos/plastic.branchexplorer
globalconfig/remoteserver_9095/allrepos/branchexplorer.conf
globalconfig/remoteserver_9095/allrepos/branchexplorer.cfg
globalconfig/localhost_8087/allrepos/plastic.branchexplorer
globalconfig/localhost_8087/allrepos/branchexplorer.conf
globalconfig/localhost_8087/allrepos/branchexplorer.cfg

New

Windows - Gluon: Incoming changes: we improved the check to determine if there are new changes available in order to show the notification bar only when there is any change that can be applied (e.g: the moves which cannot be applied are now filtered).

Bug

Windows - Plastic: Fixed two issues in the new Code Review System:

* .NET files (C#/VB.NET): When navigating to a comment, if the source file had code regions, they were collapsed by default. When this happened, the selected comment was lost.

* .NET files (C#/VB.NET): Sometimes, when navigating to a comment, the source file was not correctly scrolled to the line the comment was inserted. Now it's fixed.

Bug

All platforms - Command line client: The Incoming Changes displayed the message "Merging file 1 of 1: README.txt" twice for each merged file. The second message should be the merge result, so we changed it accordingly.

If the merge is complete, you'll see this:

Merging file 1 of 1: README.txt
Merged file 1 of 1: README.txt

If you cancel the merge (i.e. exit without saving), you'll see this instead:

Merging file 1 of 1: README.txt
Not merged file 1 of 1: README.txt

Bug

All platforms - Gluon: The update operation could wrongly load a file/directory from a xlink inside its parent xlink. For this to happen, some kind of Plastic internal ids matching was needed (the item id of the revisions loaded by the xlinks should match)

Let's see an example of what could happen.

Having the following structure in the server tree:

/game (xlink)
/game/content/textures (xlink)
/game/content/textures/texture_A.01 (file)

After the workspace update, the file 'texture_A.01' would be loaded under the parent xlink '/game' instead of under the proper xlink '/game/content/textures'.

/game (xlink)
/game/texture_A.01 (file)
/game/content/textures (xlink)

Bug

All platforms - Gluon: The updade operation didn't download the new items when they were located directly under the xlink and the xlink was changed. Fixed.