Here we are again to show you the latest in the Code Review system.

In case you missed them, there are two previous posts (here and here) where we started to summarize the improvements in the Code Review system that we are releasing periodically.

In this blogpost, you are going to see what are the new available features in the Code Review. Remember that your feedback is more than welcome!

UPDATE November 8, 2019: We updated the Limitations section because some of them don't apply anymore.


Many teams, especially in the gaming industry, use a single branch. We have greatly improved their workflow so that they don't have to struggle anymore with unneeded merges.

We still recommend task branches but we understand not all our users can't adopt them. Plastic is all about flexibility (that was the story behind its name, after all) and we decided to greatly simplify the single branch workflow.

This is the new Incoming Changes view, a way to preview, download and solve conflicts when you are behind the head of your working branch.

Incoming Changes view

Next, I'm going to guide you through each of the new features and improvements we included as part of the new Incoming Changes.

We introduced a huge change in 8.0.16.3673 (2019-10-29). From now on, your local changes will convert into controlled changes (checkout) before calculating a merge.

Some days ago, we published a new update to the Triggers guide about how filters work with triggers.

As you may already know, the trigger system in Plastic SCM allows the execution of user commands at certain points in the client or server execution workflow, in the form of shell scripts or any other operating system executable.

Among others, the trigger system in Plastic SCM will allow the developer or administrator to perform the following tasks:

  • Enforce branch creation policies like naming conventions or making sure that branch names always refer to a certain associated task.
  • Introduce before-checkin rules to enforce coding standards or create formatting rules.
  • Enforce that comments are introduced on checkin.

Triggers are created from the command line client:

cm trigger create {type} {name} {script}
  [--position=value]
  [--filter=filter-value]
  [--server=server:port]

and you must use the --filter option if you want to restrict when the trigger executes.


This blogpost is a summary of the explanation and examples that we included in the Triggers guide.

In this blogpost, we are going to show you more about what is new in the Code Review system and how you can take advantage of it.

We first shared with you an overview of the upcoming new Code Review system.

And then, we showed you the first improvements in the Code Review.

Let's see the latest in the Code Review.

UPDATE October 7, 2019: We edited the post to include a link to the latest about the Code Review system.


As you probably already know, we are working in the new Code Review system.

A prototype is ready to use since release BL3388.

We are going to describe every new available functionality and improvement through an ongoing series of blogposts. So bookmark them and don't miss any news about the new Code Review system.

Now, you can restrict merges to happen only if certain rules are met. We call this new feature "Merge Rules" and it is available both for on-premises (Team and Enterprise) and Cloud Edition.

It is very easy to set rules like "don't allow to merge branches if they are not reviewed" and "only allow merges from child branches" among others.

Previously, you'd have to write a trigger to enforce this behavior, but now it is just a matter of setting a few merge rules.