Mike is working on the main branch and has some changed files that are ready to checkin. Bob and Joe are also working on main. When Mike is about to checkin, Plastic asks him to update his workspace first. Mike goes nuts. He didn't have to do this with Perforce. Why is Plastic forcing him to work this way?

Short answer: Mike, if you want to work this way (SVN/Perforce style), please use Plastic Gluon :-P. It comes with Plastic, has no extra cost, but supports a different workflow. It is perfect for working with non-mergeable files (art, docs, blobposts...).

Long answer: it is all about merge-tracking. If you want to look under the hood of version control then keep reading. I will explain why Git, Mercurial and Plastic SCM implement per-changeset merge tracking instead of per-file merge tracking like older systems used to do (P4, Clearcase, SVN).

External tool actions have been around since release, thanks to some of you asking for them.

You can create custom actions to run on selected objects such as labels, changesets, branches, and items, and invoke those custom actions directly from Plastic SCM.

External tool actions - Branches

Add custom actions to branches and files

Okay, this is a little bit difficult to understand without an example, so I'm going to teach you how to implement two different actions: one for branches, and one for items. I'll let you tinker around with action for labels and changesets on your own, but it is just as easy. Remember, this feature is available on Windows, macOS, and GNU/Linux, but only in the regular Plastic SCM client, and not in Gluon.

For the action to a branch, I'm going to add a custom action to directly apply an attribute to the branch. This is instead of the alternative of having to navigate to attributes, then selecting the attribute I want to apply, and then looking for the value, which is a real hassle if you do this a lot, like we do.

For the action to an item, I'm going to add a custom action to directly open that item in Visual Studio Code.

Ready? Ok, let's go.

Having local repos (working distributed) is great: super-fast checkins, speed-of-light branch creation... nothing breaks the flow. In contrast, slow checkins to a remote server simply get on my nerves and drive me directly to productivity-killing time filling like checking conversations and forums on Slack.

Super big local repos with tons of history I never actually use are not good, though. Yeah, disk is cheap and all that, but 20GB local repos drive me crazy.

And, I'm connected to the internet while I code 99.9% of the time. Cant I just have lighter clones and grab the data from the central server on demand?

We have just introduced nodata replication. You only get the metadata and data is downloaded on demand from the central server.


We have just released a new cross-platform (web-based) admin tool to configure and monitor the Plastic SCM server. We call it webadmin and it is included in release

So far, we shared how we do DevOps and Trunk Based Development using Plastic SCM and a set of tools around it. But I wanted to make the blogposts short, so I left lots of notes and explanation intentionally out for the sake of brevity.

In this 5th blogpost in the series, I will cover why automated testing is so important for us, but also 2 other practices we adopted long ago: code review and explore test each task.

In this blog post we will explain how you can easily analyze your Plastic SCM Server logs to get very useful information of our server behavior and identify potential issues.

The Plastic SCM installation provides a tool (plasticlogstats.exe) that is able to parse your server logs and generate detailed reports.

We have reached the 4th installment of the series telling how we implement trunk-based development at Codice today. Previously, we covered:

Today, we will answer some common questions that were not covered before. So far, we just described the ideal cycle, but never told you what happens if tests fail, the various reasons why a task/branch can be rejected, what to do when a branch can’t be merged or how to handle broken builds. These are the topics we cover today.