CyberFlex Software is an Australian software company that has been developing software for the Heavy Glass, Automotive and Transport industries since 2001.

We've been using Plastic SCM for around 10 years now and have always been happy with the approach Plastic SCM takes to source control and customer service.

Right now, we use Plastic SCM in a fully distributed configuration leveraging the Plastic Cloud offering by using it as our central repository with each developer having their own local repository.

In this blogpost, I want to show you how this configuration works well for our team who work across multiple offices and allows for flexible working from home if required.

We are happy to announce we have a new mascot!

A clever owl that represents a wise librarian. As version control developers, we love the idea of Plastic being the librarian of your projects, and a wise one indeed :-)

Plastic SCM new mascot

Do you suffer from the occasional illness of "Ouch! The changes I did few days ago were rejected because of merge conflicts?" On a scale of 0 to 10, how annoyed are you when you have to go back to that code and fix these silly conflicts? If your answer is, let's say, 7 or greater, continue reading, and maybe you will discover an interesting proposal to take care of them at the early stages.

A DevOps medication

If you are a DevOps-aware team, you are probably familiar with concepts like Continuous Integration (CI) and Trunk-based-development, and the benefits they provide to your value stream.

You may also know how important it is to keep flow moving fast and to have instant feedback for your rejected code changes in the pipeline for any reason, so the cause of the problem is addressed sooner, before it becomes a tedious task.

But implementing processes to fit these needs could be a major step. I'd like to show you how Plastic SCM leverages its DevOps feature to easily create an actual ecosystem of automation bots to achieve all of these goals.

(This blogpost was originally published at Medium.)

I don't know about you but I've always enjoyed a good David and Goliath story. There's something about the heroic underdog standing their ground against the big foe that captures my imagination: whether it's Frodo going up against Sauron, Luke Skywalker taking on the Empire, or Plastic SCM holding its own against Git.

Ok, maybe the last isn't quite the same - but hear me out. At conferences or other events, people always ask me, "How is Plastic different to Git?" They are always curious (and at times mildly affronted) as to how we can possibly compete against the much-loved Torvalds' dominant creation that's used and contributed to by multinational giants like Atlassian, Microsoft, GitHub, GitLab, and others.

With powerful friends like that, it may seem entirely crazy to put your trust in Plastic. And yet, over 2500 developer companies including large-and-small game studios, insurance agencies, health care companies, aerospace companies, automotive companies, and more have done exactly that.

Us versus the rest of the Empire

So, what is it that makes us different? In short, we've taken the age-old underdog story and tweaked it. While Luke Skywalker exploits the Death Star's single weakness to entirely destroy it, at Plastic total destruction isn't what we're after. At least not entirely.

You can extend the actions available for branches (and many other objects) by using the external tools feature.

Unified diff

This blogpost explains how to create a custom action to run a unified diff operation for a Plastic SCM branch.

Códice has been around since 2005, when we decided we wanted to create a better version control system. Since then, we have created Plastic SCM, a solid version control system that many teams of all sizes around the world pay to use. And it is important to note that they had many options to simply grab a version control system without having to pay a dime, but they opted to purchase our software, and keep us in business.

Well, today, I'm writing down the list of all the software components we develop, just to share with the team and users, the scope of the products we make here at Códice Software.

Pull requests are broken. Ever experienced that? Take a branch with only 3 small changes and it will get a whole lot of comments and suggestions. Take one with +100 changed files and it will get none.


Is there a fix for this? We believe there is. What if every checkin was done with reviewers in mind? What if we take the approach that "checkins must be created for people to review, only incidentally for authors to deliver their work"?

A little bit of background

Yesterday, I was writing a short guide on how we work for a new developer joining the team. Some sort of "how to use Códice Software" inspired on readings like Basecamp's Handbook and the "how to work with me" guide described in High Growth Handbook.

Then, I was about to write down our oral tradition on how to "work on task branches". And I realized that... well, it would deserve a blogpost. So, here I am.

We treat checkins very carefully, and I'm going to explain the secret sauce we cooked up for really great checkins that lie at the heart of task branches.