In this blogpost, we are going to show you more about what is new in the Code Review system and how you can take advantage of it.

We first shared with you an overview of the upcoming new Code Review system.

And then, we showed you the first improvements in the Code Review.

Let's see the latest in the Code Review.

UPDATE October 7, 2019: We edited the post to include a link to the latest about the Code Review system.


As you probably already know, we are working in the new Code Review system.

A prototype is ready to use since release BL3388.

We are going to describe every new available functionality and improvement through an ongoing series of blogposts. So bookmark them and don't miss any news about the new Code Review system.

Now, you can restrict merges to happen only if certain rules are met. We call this new feature "Merge Rules" and it is available both for on-premises (Team and Enterprise) and Cloud Edition.

It is very easy to set rules like "don't allow to merge branches if they are not reviewed" and "only allow merges from child branches" among others.

Previously, you'd have to write a trigger to enforce this behavior, but now it is just a matter of setting a few merge rules.

Trunk-bot, one of the included mergebots, now takes into account code reviews and is able to merge reviewed branches only.

We are improving our built-in code review system, and we want to make it as easy as possible for you to take advantage of it. That's why we created Merge Rules, and why we have now enhanced the mergebots.

For those of you unfamiliar with mergebots, a mergebot is a piece of software that runs on your Plastic server and tries to merge task branches once they have met given criteria. Previously, mergebots only checked whether a branch had a given attribute, or if the associated Jira had a given status on it. Now we have added the branch review status into the mix, so you can easily incorporate code reviews into your CI/CD process.


Let's see how to configure this new setup.

Here is something pretty amazing. Plastic can merge methods that were moved across files.

I'm going to move a C# method to a different file in a branch.

In a different branch, I'm going to modify the original method.

Plastic merges this without human interaction and applies the change correctly in the new file.

Ta-da!

We are working on a new code review system. Yes, I know this is the kind of blogpost that will quickly get out of date, but I felt the urge to share with you, dear Plastic user, what we are working on.

I'm going to share what we are doing, what you can expect, how it is going to be better than any pull request system to date, why it took us so long to get started, and how code reviews are central to our version control vision.

Just to give you an overview of what it will look like, let me share a screenshot of one of the design docs:

UPDATE September 26, 2019: Added information on how to distribute branch explorer filters through Plastic SCM's Global Configuration.


One common workflow in other version controls such as Git is as follows: you create your bugfix or feature branch, and once you are finished with it and your changes get integrated, you delete it. Plastic SCM, for traceability reasons, does not support deleting branches. Because branches are the central part of our development philosophy, both the core and the GUIs can handle hundreds of thousands of them without a problem. (Our main repo has almost 25K branches right now, and that's actually very few!) So, you don't have to delete them for performance reasons.

But, you can "archive" branches you no longer need to reduce the clutter, and even to adapt your workflow from your previous SCM tool if you are unfamiliar with Plastic SCM. Let me show you how!