SemanticMerge just turned 2.0 and we’re all very proud of it. It is the first major release since we launched the product back in 2013.

2.0 features a totally redesigned user interface that makes it more suitable for daily use. Now it is not just the tool you use to handle tough merges. Thanks to the new design it is now the tool you can use on a daily basis for a wider range of scenarios. It is more intuitive and easier to use.

It happens quite often -- teams moving away from Git to Plastic ask me what happens with features like rebase and even commands like rerere. They normally jump to Plastic because of the big files, the GUIs, but they want to ensure that they won’t miss any of the things they love in Git.

This blogpost tries to answer these questions, and more specifically: why you won't miss Git-style rebase (or history rewriting entirely) nor rerere in Plastic.

And it all lies in how Plastic handles branching differently than Git...

Sideloading is the mechanism to install Windows Store apps without downloading from the Windows Store. This would occur if we want to distribute line of business (LOB) apps or for testing purposes.

For many Windows Store apps, the publishing flow is usually pretty basic and as easy as following this wizard:

Windows Store apps - Wizard

Using this wizard, we can generate our app packages, and upload them to the Windows Store in an easy way. But sometimes we face more complex scenarios beyond the scope of Visual Studio. Sometimes we don't want to publish our app but need a way to distribute it in our organization.

Some common scenarios that could cause this situation are:

  • Generating app packages within a Continuous Integration flow.
  • Automating a Sideloading scenario to distribute the app outside the Windows Store.
  • Installing on the same machine different versions of the app for different environments (Development, Release Candidate, Production, etc.)

This article will explain the mechanisms that will allow us to cover these three scenarios.

A few days ago the Plastic SCM crew (me included!) went to the dotNet Spain Conference 2016 in Madrid. It was an awesome experience. We had the chance to see the latest .NET technologies in motion and learn a lot from great Microsoft experts. We even got mentioned by Satya Nadella himself!

The next day the HackForGood hackathon took place in Valladolid (among many other places). Carlos and I were present as mentors, and we were impressed by the enthusiasm and the innovative ideas of the participants. While we were around talking with the developers, we took notice that all of them used some task system to organize their work. Most of them used Trello because it's simple and fast, it doesn't require setup and as a cloud application, it's accessible anytime, anywhere.

Seeing this, I realized that Plastic SCM could easily be extended to display tasks data from Trello, just as it already does for many other issue tracking systems. It could be a great option for small teams or individuals working in prototypes, side projects or just coding as a hobby! So, encouraged by the DIY spirit lived at the dotNet Conference I decided to implement that extension myself.

When I run a demo of our source code merge program, a developer occasionally raises a hand and asks, "What do you mean by 'three versions' of the file being merged?" To answer this and explain how three-way merges work and why they are important, let's start by taking a look at the traditional two-way merge.

This article was originally published at the Dr. Dobb's portal.

Plastic SCM release 729 includes a number of improvements in the version control integration with Unity 3D. Most of them are related with a better integration with Plastic Gluon our GUI and workflow for artists and designers in game dev teams.

Gluon now actively handles .meta files to prevent to forget them during checkin or workspace configuration. The Unity plugin adds a way to invoke “Gluon workspace config” and better progress during the update operations.

As you probably know by now, Plastic SCM requires Mono, the open source.NET Framework implementation, in order to run on non-Windows platforms: Linux, Mac, OpenBSD... Our public repositories distributed Mono version 3.0.3 so far, which we had thoroughly tested to be completely sure it could run Plastic SCM flawlessly.

However, as our GTK# GUI grew, we bumped into compatibility problems and minor issues that prevented users from having the best Plastic SCM experience. This is the reason why we decided to upgrade the shipped Mono version to version 4.3.0. Quite a leap, isn't it? :D

We've built new packages to allow Fedora, RedHat/CentOS, OpenSUSE, Debian and Ubuntu users to easily upgrade their installations, starting with version These new packages will conflict with the previous Mono 3 ones, so the upgrade operation might require manual package dependency resolution. Don't worry, we'll walk you through it!

Alternatively, if you've never installed Plastic SCM on your Linux machine before, you just need to follow the installation instructions available on our website.

Important: This walkthrough will assume that both Plastic SCM and SemanticMerge are currently installed in your machine. If that's not the case, you can of course adapt the instructions to skip the software you don't currently have.