DDJ: Pablo, how has the world of software configuration management changed over the past few years? Are distributed systems at the top of the list?

PS: For the past year, software configuration management (SCM) had actually diverged into two different paths: one is toward usability, the other toward distributed development. Users don't like cumbersome, hard-to-administer, and usually arcane SCM systems anymore. They prefer robust functionality in terms of managing and merging branches and developing in multi-server environments but they also want ease-of-use. Without ease-of-use, developers may reject a SCM product outright, no matter how robust and powerful its features are.

On the other hand, we see new systems focusing on distributed development, ranging from multi-site to fully distributed development, where each developer is running his own repository copy. It is important to support a development team with as many features as it requires and to provide each team with the ability to customize its development process. This combination of robust functionality, ease-of-use and versatility will help each development team determine how to use its software configuration management solution.

Our goal with Plastic is to combine robust functionality with ease-of-use. Plastic is intuitive-to-use, lets developers easily deal with branches, and implements fully distributed development ranging from multi-site to full distribution, including merging branches modified at two sites simultaneously.

DDJ: Does the movement towards threading and concurrency have any impact on SCM?

PS: I believe threading and concurrency are definitely trends, and we developers need to make an effort to keep pace with these trends.

Stability is the key in a heavily threaded environment. Each modification made to the code base can have an impact, so correctly choosing the baseline you're working with, making sure it's stable, and correctly isolating developer's changes are really important to manage the development cycle. Hence, SCM plays a really important role.

A proper SCM strategy will help developers version their own intermediate changes to correctly isolate independent changes, and manage the integration of code, branches, and so on.

Strong SCM is the key here. A number of SCM solutions have problems dealing with branches (i.e., lack of merge tracking, lack of proper merge support, unable to handle thousands of branches, refactor (true renaming and merging) problems, etc.). They don't provide developers with the freedom to choose their preferred development strategy.

DDJ: It's my understanding that Plastic, Codice Software's SCM offering, is written in C#. Can you tell us a bit about that?

PS: Sure. The decision to write Plastic SCM in C# was made because C# is all about development speed and performance balance. I had a C/C++ background before starting this project. I was also familiar with Java and Delphi. But my preference was clearly C++. It is the language for system code, isn't it?

But some people on the team introduced C# as an option. "Development is much, much faster when you use C#," they said. I made a sample by dynamically loading classes from different assemblies (shared libraries), and connecting them to each other to generate some sort of processing chain. I just knew what I wanted to achieve and was able to write it in minutes. I compiled the code and the program ran on the first try (I wasn't experienced with C# then). This really shocked me. C# is different: it is really easy, and it is really powerful.

And then I learned about remoting. It was really key for me. Years ago I developed lDCOM code. I was also familiar with Java RMI (I worked on an Inter-Xlet (IXC) implementation while working for Sony Digital TV). That's when I appreciated how easy and elegant remoting was!

Then I was worried about multi-platform: Every serious SCM out there has to run on a variety of operating systems and C# was all about Windows until the Mono Project entered the scene. Mono was crucial in my decision to write in C#. Now all of our GUI and server code is running on Linux and the GUI simply looks great!

Plastic server, command-line client, and Eclipse integration run on Linux, Solaris, and MacOS and the GUI is fully supported on Windows and Linux-based systems. We're working on the MacOS GUI right now. It looks superb (probably better than any other OS so far) but it isn't stable enough yet, so there's still some work to do before officially releasing it.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!