Release Notes

Public Jul 12 2019


Windows, Plastic: Here goes a prototype of the upcoming Code Review system.

It is not yet functional but you can give it a try if you start your Plastic this way:

plastic --codereview

And then go to edit an existing Code Review.

Remember, this is just a prototype, so the comments won't be stored. The goal is just to try how good the new comment system works and get feedback.

It is now finally possible to reply in comments.

And also create threaded conversations, something we always missed (and didn't find on competitors either).

Hope you enjoy it. This is just a first step to implement our Code Review vision :-)


All platforms - Client-side triggers: From now on, missing client-side triggers won't make trigger execution fail: the next trigger in the list will be executed instead. Bear in mind that by "missing client side trigger" we mean "when the executable of the trigger is not accessible by Plastic process" (CLI or GUI). If the trigger executes, but fails, will make trigger chain execution fail as before.

This is useful when you store triggers in a repository: on first update, the trigger is not present, and thus it is skipped, instead of making update operation fail (forcing you to remove the trigger, run the update, restore the trigger…)


macOS - Plastic: We changed the cherry-pick link color when the Dark Theme is enabled. They were extremely difficult to notice until now, so we're dragging them out of the shadows! Take a look at how it looks:


Xlinks: Fixed a couple of scenarios where the user couldn't perform changes inside an xlink due to the "Can't perform a checkout in an edited xlink" error.


The first one was related to checking-in partial changes inside an xlink.

Having the following structure in the workspace, where /xlink is an xlink :)


If we add a couple of files:

cm add /xlink/bar.c
cm add /xlink/qux.c

But we only checkin one of them:

cm ci /xlink/bar.c

We will not be able to checkout /xlink/foo.c or add a new file /xlink/aux.c


This happens also when checking-in changes inside an xlink but in a different way.

Let's suppose that we are committing some changes inside and xlink and there are not new changes in the xlinked repo so it can be correctly completed. BUT, someone created a new changeset in the parent repo so a merge is needed in order to complete the checkin for the parent repo although the changes inside the xlink where correctly checked-in.

At this point, we are in the same situation than in the previous scenario. We are not able to checkout or add any new file inside the xlink.


All platforms - Plastic, Command line client: When undoing complex locally moved changes, you could get the error "The item XYZ already exists!". That's been fixed. If you want a deeper explanation of the problem, continue reading!

Imagine this scenario - you have a deep tree structure and you do the following operations outside of Plastic SCM:

1) Rename a directory.

2) Rename a file inside said directory (from name A to B).

3) Move up a file deeper in the tree structure to be alongside the recently renamed file.

4) Rename the file you just moved to have the same previous name as the other file you renamed (from name C to A).

With a little diagram, we have transformed this (simplified):

 |- /b (1)
 |   |- fileA.txt (2)
 |   |- /c
 |   |   |- fileC.txt (3)
 |   |   |- some.txt
 |   |   |- more.txt
 |   |   |- files.txt
 \   \   \- here.txt

Into this:

 |- /x (1) (LM from /a/b)
 |   |- fileB.txt (2) (LM from /a/x/fileA.txt)
 |   |- fileA.txt (3) (LM from /a/x/c/fileC.txt)
 |   |- /c
 |   |   |- some.txt
 |   |   |- more.txt
 |   |   |- files.txt
 \   \   \- here.txt

…where numbers (1), (2) and (3) indicate the item correspondence (directory or file), and (LM) indicate the new status from said item.

Now, before doing further operations (undo, checkin, and so on), Plastic SCM needs to convert local changes to controlled ones. The problem was that, because of how Plastic SCM calculates precedence between local changes, it was trying to apply first the LM on item (3) instead of on item (2). An item with the same name and path already existed in the metadata (because changes on (2) were still to be applied), and the command execution failed. Now, Plastic SCM correctly calculates locally moved changes precedence in order to apply them in the right order.

This is a good moment to remember you that, for doing complex restructurings, you can use the GUIs or the command line client. Plastic SCM will update the metadata with each move, delete, and rename operations, which makes the process much less error-prone.