Yesterday, Codice Software released the first official build of PlasticSCM 2.0. PlasticSCM is a Software Configuration Management (or Source Control) system written entirely in .NET, which gains cross-platform compatibility through the Mono Project. To date, the command line client will run on any platform where Mono is supported, and the GUI is available on Windows, Linux, and Mac OS X.
I’ve written before about Plastic and SCM in general. And I’ve been using Plastic on a trial basis for several months at my current job, including testing all the interim builds of the software. PlasticSCM is a great solution for parallel development, and with some of the new features in 2.0, for distributed teams as well. I really, really enjoyed using Plastic, as I prefer a parallel development model, where I create a large number of branches, keeping the mainline clean and stable. The only problem I had with Plastic’s model, was that it seemed impossible to mark a branch as ‘inactive’ so that I could hide it once I was not doing any active development within that branch.
Ultimately, our office decided against Plastic. A co-worker was an old-school Perforce user, and I had no choice but to admit that today Perforce is a more mature product. It has a published API. It has a triggers and event system which we can leverage for things like keeping our integration server always up to date, or any other continuous integration we might do. I’ve had many conversations via e-mail with the Codice team, and I appreciate their accessibility immensely, and all these things are planned features, but they don’t exist today.
In short, we chose Perforce because it was the best product available today. I personally believe that in six months, or a year, maybe two at the most, Plastic will have those features that I wanted today, and then some. Plastic will continue to be my go-to product for development teams that don’t yet have Source Control. Codice provides excellent support, they’re available, and they listen to customer feedback (and I hadn’t even given them a dime, I’m really sorry for that). Plastic doesn’t pretend to be a complete solution like Microsoft Team System or Borland’s StarTeam, both of which provide heavy issue/defect/feature tracking, as well as integrated project management tools. Plastic exposes data for Project Managers, but doesn’t provide things like Gantt Charts and time-tracking built in.
One thing I’m going to really miss about Plastic as I move toward Perforce at my current job is it’s clean representations of the current state of the source tree. On Perforce, each branch is represented at a new directory under the main depot, and each branch is automatically populated with all the files you’ve marked for the branch, which can include a very large amount of source. In Plastic, you denote the ‘parent’ branch of the new branch, and alternatively a Label to branch from. The new branch is completely empty itself, but it inherits the full state from the parent branch. This is why choosing a label is so important, because without the label the state of parts of the tree can change underneath you, labels keep child branches stable. Items are branched on the individual level only when you choose to commit changes within that branch. It’s a clean mechanism to keep the tree clean, and it also helps ensure that you know with full certainty which branch you’re checking out from and committing against.
Perforce is a very good product, but I don’t see Perforce changing too much in the future. Plastic is a good, but it has a fast, dedicated, responsive development team that I believe will be able to create a great product. I wish them the best, and I’ll strive to send some customers their way when I can.