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.

(Applause).

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 6.0.16.1699.

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.

This is the third installment in the series of blogposts telling how we develop Plastic SCM. In the first two posts, we covered what our new working cycle looks like once we moved to trunk based development and then we gave a brief overview of the meaning of release versus deploy.

In this third blog post, we will be looking back and filling in some gaps. What exactly is trunk-based development and how does it blend with task branches?

If you read our previous blogpost about how we do trunk based development with Plastic SCM, you probably have a few unanswered questions.

This blogpost is the second in the series and covers something we find interesting: the difference between deploying and releasing.