A few weeks ago, Git announced support for sparse checkouts and partial clones in beta. Since reading it, I have wanted to share my thoughts with you, so that you know we don't live in isolation of what Git does, and also, that we have an opinion about it. Hence, my intention is to share what we think these new features when compared to the current Plastic SCM functionalities that we already have in production.

In short:

  • The new Git features are about trying to avoid the mandatory local clones from growing too big by just cloning parts of the original repo.
  • In Plastic, this has been possible for a few years already but in an even more powerful way. On top of that, the clones are not even required if you decide to work centralized.

Why do you need a good ignore.conf?

Unity, like many other editors such as Visual Studio and Visual Studio Code, and many others, creates a wide variety of files that shouldn't be part of the repository. The ignore.conf file contains a list of rules that makes those files and directories not to be tracked by Plastic SCM.

The main advantages of a good ignore.conf are:

  • Smaller repository: Big assets are kept local; therefore, the repository size doesn't grow.
  • Avoid constant conflicts: Automatic files created by IDEs are changed continuously. If they are part of the repository, the users will face merge conflicts every time the IDE changes them locally.
UPDATE February 3, 2020: We updated the Restrictions and missing features section because some of them don't apply anymore.


The new Code Review is finally available for macOS starting on release 8.0.16.3859.

You can now request changes to code, ask questions, place regular comments and have full conversations (threaded if needed) about a particular section of code.

Yeah, ok, maybe I went too cinematographic with the title.

We are redesigning the GUIs for the upcoming Plastic 9.

We'd like to share with you what we have and get some very early feedback, to ensure the improvements really make sense.

What's your first impression? Anything you miss? Do you like it overall?

Many more screenshots inside 😉

A few releases ago, we published a bunch of improvements related to the Plastic Proxy. These updates are about monitoring space and cleaning cache up on disk. This helps you manage your Proxy behavior.

Let's see in detail all these improvements.

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.
UPDATE November 21, 2019: We updated the Limitations section because Incoming Changes is also available for macOS.


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.