Distributed Version Control

How it works

How it helps in the enterprise

Distributed version control is not only for open source projects. Plastic SCM was designed from the ground up to bring the best of branching and merging, parallel and distributed development to teams creating commercial software and enterprise applications.

There are some features to take into account when considering DVCS for commercial software developers:

• Commercial teams are normally not as massively distributed as the hackers on the open source projects. They normally share an office, or a set of offices, and maybe some of them work from home.
• The "main" repository is a requirement and forking totally independent alternatives out of the principal repository is normally not the desired scenario to keep costs low and productivity high.
• Contributions are not done in the developers' "spare time" but normally are responding to tight schedules.

And still, DVCS is great for these teams since:

• It enables teams to work together from different locations, contributing with each other, and avoiding slowdowns due to network issues.
• They need strong branching and merging, and this is something DVCS is all about.
• It enables developers to work at home, at a customer site, or even roaming, while still being able to contribute to the project.

What Plastic SCM adds on top is:

• It is fully designed, from the ground up, to work in companies: from small shops to enterprises. It is not a layer on top of Git, Mercurial, or any other DVCS: it is a full featured distributed version control stack.
• It is graphical, focusing on productivity, visualization, and ease of use- something required by big business. The Branch Explorer, the sync view, the IDE integrations, the GUI, and many more tools, make a big difference.
• Strong security and access control provide fine-grained checks, policy enforcements and compliance.
• The ability to run in both centralized and distributed modes: you can have a central server on one site, with all developers connecting to it (reducing potential issues derived from full distributed setups on heterogeneous environments), and then certain teams, developers, or sites running other servers and connecting to it. All options are available. Open source DVCS force one to work in a distributed mode, with a full replica at each developer machine.
• Standard database storage: all data and metadata are stored on the company's database of choice: simplifying maintenance, administration, backup, setup, and tuning.
• An improved merge mechanism able to deal with many of the business world's common scenarios and with the precise file and directory tracking that commercial projects need.

What's in here for ClearCase users

ClearCase developers might say: "We were distributed as of 20 years ago thanks to ClearCase MultiSite!". And they're right... Almost!

The most notable differences between ClearCase MultiSite and Plastic SCM from the "multi-site" point of view are:

• ClearCase MultiSite forced you to have a "master replica". You're either the master of a branch or you are not. Plastic SCM doesn't impose any limitations on the concurrent modifications to branches.
• Setting up and administering CC MultiSite was a daunting task. With Plastic SCM each server, by default, can replicate to any other, independent of the database backend they use or the operating system they run on.
• ClearCase MultiSite was incredibly expensive. You can set up as many Plastic SCM servers as you need. We do not charge by server. Install one on each developer's machine if needed. Or two. No extra cost.
• Distributed - fully distributed - means each developer has a replica. You can install a lightweight Plastic SCM daemon on a laptop. Don't try to set up a CC MultiSite on anything other than a full-featured corporate server monster.

So, while we at Codice Software were inspired by ClearCase, and we've always focused on making the teams moving away from CC feel at home with Plastic SCM, our product is a totally different and vastly improved system compared to good-ol CC MultiSite, outperforming it in every aspect.

Open Source development

DVCS was born in the open source world, as a way to better enable collaboration in highly de-centralized teams, that can't share effective access to a central location.

DVCS was created to handle the Linux kernel development, but since then it surpassed the original goals and became a global resource for developers.

In the last few years, all major open source projects abandoned Subversion, the former open source king, and headed towards systems such as Mercurial and most notably Git, the Linux kernel champion.

Open source projects can be massively decentralized. Theoretically DVCS means a "central server" is not required anymore, since each "peer" has his own replica ensuring:

• Fast access to data (accessed locally instead of over the wire)
• Simple collaboration between peers (each developer can share changes with any other developer)
• Safety: each developer has a copy so it is virtually impossible to get a central site down or lost, copies and backups are everywhere.

However, not requiring a central repo doesn't mean one doesn't exist. At the end of the day, there's always a "blessed" repository, which conceptually plays the role of rendezvous point or central, and is the one that developers refer to when they contribute changes.

Open source DVCS tools such as Mercurial, Git, Bazaar and others, evolved to deal with open source development. They're great for that purpose and helped to create a version control revolution, breaking the former "status quo" and turning version control into a productivity factor in teams.

Plastic SCM is the only DVCS designed for teams developing commercial software, from small teams to huge companies, and as such it brings in features like ease of use, access control lists, standard database based storage, powerful graphical user interfaces, and professional support.

Mind the gap distributed as buzzword

DVCS has become a buzzword too and as such is easy to find in the wrong context.

A DVCS is a version control that lets developers work while totally disconnected from each other. This means:

• Having a proxy that caches requests on one side is NOT distributed. It's fine under some circumstances, but it is NOT distributed. Many vendors of centralized version control systems tried to jump aboard the DVCS ship with simple proxies. This is cheating.
• Working through the internet is NOT distributed either. Just having a TCP port and a web UI doesn't mean the system is distributed or that it enables distributed development.

Having a distributed version control system means being able to set up lightweight replicas even on developer's laptops, which are able to replicate changes (push and pull) to any other server easily.

The underlying architecture is so different from traditional centralized systems that it requires almost an entirely new development environment to get it adapted to the new working model.

That's the reason why Plastic SCM is, to date, the only commercial distributed version control system on the market. So mind the gap and don't get fooled: all the other commercial products are NOT distributed and at best provide some sort of cheap cache system that is far from being DVCS.

In the open source world Git, Mercurial, Bazaar and many others have been used by companies to build notable wrappers (GitHub, Bitbucket, etc.) to try to get them adapted to the enterprise without going through a full development cycle.