You can now hook web triggers to Plastic SCM operations. It has been a reality for years on the on-premises Plastic SCM Server, but now Plastic Cloud also supports it!

Do you remember we recently released cloud2? Web triggers is one of the new features in the new Cloud. Stay tuned because there's much more to come 🙂

What a web trigger is?

Somebody introduced a bug in the codebase, as a failing test demonstrates. But the test is the symptom, and the cause might be too deep to know exactly where it is.

It would help a lot if you were able to pinpoint the changeset where the bug was introduced, but that's manual labor. You must first switch your workspace to a changeset, then build the necessary assemblies, then pass the specific test, and based on the result, decide which is the next changeset to test. That's an awful lot of steps!

That's where bisect is useful, and that's what I bring you today.

Let's bisect a Plastic SCM repository using PowerShell!

We just turned on our new Plastic Cloud, code-named cloud2, for new users evaluating and purchasing, while we continue migrating all current customers from cloud1 to cloud2.

The new cloud2:

  • It's incredibly much faster. Better servers, more efficient, and intensive memory use and caching. And much faster metadata storage and improved data transfer.
  • Dramatically reduces latency. Metadata servers closer to your location.
  • Enables long-awaited features: shelves are now available in Cloud, move changesets to other branches, and real soon cloud triggers and many more. We have a much solid foundation for feature parity with on-prem servers.
UPDATE March 17, 2020: You can now read a summary about what were the main features launched during Plastic 8.0.

As every year, we jump to a new number, 9.0 this time. For all of you using subscriptions, it will be transparent.

UPDATE March 10, 2020: Edited the Install on macOS from tar.gz section. We updated the instructions for installing the Plastic SCM server .Net Core on macOS.
UPDATE March 2, 2020: We edited the Current limitations section because the Plastic SCM .NET Core Server includes WebAdmin, WebUI, and DevOps (mergebots) since release

Great news! We just published the Plastic SCM server built on .NET Core, the cross-platform, rock-solid, super-fast and officially supported framework.

The new servers are available for Linux, macOS, and Windows beginning with version

The new servers are fully compatible with your current installation, but as of, they don't include WebAdmin, WebUI, and mergebots. We'll release a new version packaging these features soon. These features are available since version

The Linux servers are available as tar.gz and also regular packages.

Windows and macOS servers are only available as zip and tar.gz at this point. We'll make them full regular installers soon.

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.