What are the advantages and disadvantages of Distributed vs Centralised SCM?

Here are my thoughts...

1. If your code is distributed across many sites/depots/servers/whatever, does that mean that your ability to do a full build is affected whenever one of them, or the network to it, is down?

2. With distributed code, how do you do a consistent backup of your entire product?

3. I like multiple site solutions, as long as there is no need to do partitioning and re-synchronization operations. This seems only feasible if the entire product exists at all sites, or at least some subset of the sites.

4. When you distribute code across sites, it's probably more important that you have an at-rest encryption capability, because it's typically under less control. So if someone gets access to the files, they still don't have the goods.

5. Centralized repository with good remote access is nice, but it doesn't cut it when you start doing things like full product delta reports (vs your local workspace), full builds, etc. unless you have high speed connectivity all the way through.

These are all real concerns that have to be addressed by an SCM tool, and indeed by an ALM tool. I don't like tools that make me administer separate multiple site solutions for each component of the ALM solution (and usually not for all of them).

In CM+ here's what we do.

1. Centralized repository
2. Multiple Site option allows replication of all transactions at all sites in real time. (So each site looks and feels like a single site centralized repository.)
3. At-rest encryption option (applied at library creation time)
4. Ability to restrict certain files (or file types, products, etc.) to specific sites.
5. Access to file controlled by user roles/permissions, not by location of the file. So change sites and you have the same data and same permissions based on your user id.
6. Apply multiple site capability across all ALM functions, not just source code.
7. Use multiple site feature to provide warm-standby disaster recovery and live, up-to-date on-line backups.
8. Allow you to disconnect a site and have full read access and limited write access to the repository. So if you needed to take it to the space station, or on a flight, or out to sea.
9. Allow automatic recovery from network outages so that if you're connected to the network on the space station and you lose connectivity in some parts of your orbit, you are automatically resynched when you regain connectivity.
10. Allow remote access both through a native interface, with intelligent caching, or through a web interface.
11. Allow near-zero administration for the multiple site solution (CM+ MultiSite).
12. Ensure that schema changes (for your meta data), and process changes are automatically propagated across sites in near real time.
13. Provide an option for automatic propagation of user interface customization (by default, this can be site specific).
14. Ensure that all inter-site traffic is encrypted.
15. Use the multiple site framework to monitor synchronization for any potential problems.

As a commercial organization, centralization is important. I don't buy the suggestion that distributing data minimizes backup times, server delays, etc. If that is the case, you're using old "BIG-IT" technology, which generally is server-centric, instead of using smart clients.

I really don't think cloud computing should apply to CM/ALM, unless its pseudo-cloud (e.g. having IBM host your repository for you).

So those are my thoughts, along with how we have integrated these thoughts into the CM+ product.

lincoln wrote: "My vote is Centralized. Distributed (ie; Git) are not suitable version control systems for mature software companies."

But there are less and less of those.

Anyway, I disagree with your arguments as well as with your conclusion.

Commercial systems like UCM have wasted the time and efforts of developers for 10+ years. Commercial companies cannot afford being kept captive of vendors.

Anyway, companies raising money on the stock exchange try only to save short time money, so these considerations do not even affect them.
For the security aspect, data is best secured by being replicated, not held centrally. Secret and single point failure systems are just doomed.

Marc

Marc,
While I agree that UCM and other semi-fixed process-based centralized tools have kept companies captive, certainly you must agree that Neuma's CM+, the most centralized CM/ALM tool, is quite the opposite.

It is priced low, typically under $1000/user (for ALL ALM functions, not just CM, and this includes its CM+MultiSite, the most advanced multiple site CM/ALM tool in the industry).

It allows full customization of Process, User Interface (menus, quick links, tool bars, dashboards dialogs, etc.), Roles, Data Schema, etc. while providing a very extensive, but lean (approx. 1+ line of code per configured item) customization capability, well beyond the likes of script intensive tools. Customization is INTERACTIVE, FUN, EASY and FAST.

The underlying technology ensures longevity of the solution. The oldest CM/ALM libraries are more than 20 years old and still contain every bit of history.

To further ensure that corporations are not locked it, it has near-zero administration - that means you don't need a CM Tool administrator, only someone who can occasionally help with upgrades (typically minutes), as well as do some customization tweaks.

Neuma is always willing to help with customization, and usually at no cost, since customization is done at such a high level that makes it easy to do, in most cases, the same day, through an email exchange.

And because CM+MultiSite extends across the entire repository, it's not just the version control that benefits from it - every ALM function, AS WELL AS ANY NEW FUNCTION ADDED BY THE CUSTOMER.

The integration of all the ALM functions plus additional custom functions into one interface, with one point of minimal administration, fully custom role-based user interfaces and easy customization lead to a dramatically advanced user experience.

Point-and-click, rapid data navigation.
All my important data accessible through a single dashboard.
Advanced, 35 year-old mature CM technology that reduces the complexity of the user experience while advancing the capabilities of CM beyond the industry norm.

So, in summary... Centralized CM/ALM, DONE RIGHT, is not just better than distributed, and best-of-breed alternatives - it's essential to being truely competitive and having all the information at your fingertips for the best corporate, management, and developer decision making.

Joe

MarcGirod wrote: "But there are less and less of those."

True, mature software companies are becoming extinct.

Marc, I'm speaking from experience on my current team.

My developers hate the tool yet we've been dictated by our architect to use it. The training curve in learning it is steep and we continually have something commited that shouldn't be. The concepts used (ie rebase, squashing commits, etc.) are foreign to structured SCM practices and fly in the face of stability.

Getting new developers who already have Git background is difficult (try searching for Git expertise on Dice) so we have to set aside training time for them to grasp the huge paradigm shift.

Git is essentially counter-productive in projects who need to quickly get version control in place. I get told whipped with the 'old technology' noodle each time we come across something that doesn't work (like getting hooks implemented in existing GitHub projects?) but the key here is in SCM practices, established means stable.

I agree with you on UCM, totally out of bounds on weighted processes. I'm a Subversion fan and know that I'd be able to provide my team better support using it than Git.

One of the issues that concerns me with distributed SCM is that of tracking what is happening. It obviously works great in the open source world it was designed for where you don't necessarily care what others do or how many others do until they seek to contribute it back (in which case there are bottlenecks which are the human maintainers).

In a commercial world, you might wish to know a little more about who is working on what, and why Fred hasn't checked anything in for a week or two. Also, you may wish to know that a potential collision is coming up (2 or more people/teams working on same area) and take account of those things in your planning.

I was interested in the talk that originally started this thread - the organisation had started wrapping their own control stuff on top of git.

I think there needs to be a separation between Centralized vs Distributed SCM from some of the specific open-source implementations. Also we should be clear on the difference between use of DVCS to achieve "full repository replication" (or mirroring) versus using true distributed capability.

Among the main differences I saw when the started becoming popular just over a decade ago were:

• Developer "workspaces" can be a first class repository (complete with "private versioning"), which helps resolves some issues regarding backup/recovery of developer workspaces (and introduces some others)
• There is a form of perceived "empowerment" that developers feel they have when they get to have their own workspace as a first-class repository. They don't have to have someone elses central hooks/triggers and procedures imposed on them (this is often a big "minus" to others trying to impose some semblance of centralized standardization or control). They don't necessairly have to "adhere" to such standards until such time as they submit their change to the central repository. This is like the version-control equivalent of the design pattern that dictates "program to an interface, not to an implementation", and in this case it is more like CM to an Interface, not to an Implementation!
• Centralized repositories that "collect" or "aggregate" other change-sources have the ability to "(task) branch-on-demand" instead of "(task) branching in advance" -- meaning as long as contributors have a way to "package" their changes as a single "commit" or change/patch-set, they don't have to create a branch ahead of time just in case there might have been parallel activity. Instead the need to branch (or not) can be deferred to the "last responsibile moment" at the central repository when the change is submitted and the branch can be created only when necessary. 

Well before Git came along the main "reference" implementations of distributed VCS were pretty much boiled down to (Gnu) DARCS and the BitKeeper. Those might be better ones to look at as being more "conceptually complete" than Git or even Hg or Bzr, etc.

I always liked David Wheeler's essay on the subject, and then a few others came along, like the one from InfoQ.com and another essay by Eric Raymond, and another by Ben Sussman.

I blogged about a dozen or so good links back in 2008 at http://blog.bradapp.net/2008/02/distributed-version-control-systems.html -- I hope there are some better (or more up-to-date) pages available now.

• DVCS vs CVCS essay by David Wheeler
• Distributed Version Control Systems: A Not-So-Quick Guide Through 
• Wikipedia page on Distributed Revision Control 
• Eric Raymond's Understanding Version Control 
• Ben Sussman on the Risks of DVCS 
• Ian Clatworthy on Distributed Version Control: Why and How 
• Ian Bicking on Distributed vs Centralized VCs 
• Another blog-entry on DVCS vs VCS 
• Introduction to Distributed Version Control Illustrated
• Choosing a Version Control System
• Distributed VCSes: git vs. Mercurial vs. SVN
• Why Distributed Version Control matters to you, Today!
• Distributed VCS for the other 80%
• Distributed VCS Shootout Redux
• The New Breed of VCSes
• Why Distributed VCS?
• Zooko's Quick Ref Guide to Free DVCS