We hear so much about the technical advantages (speed, offline committing, instant branching, cherry picking, rebasing) that we often forget the real advantage of DVCS: the D. That this article starts with the technical advantages makes me think we've done a bad job selling tools like Git and hg.
Yes, Rails still uses a 'central' development model. But it's trivial for me to fork Rails then track development, add my own features, fix bugs, or go my own route with a personal or corporate version of the framework. Many people do this. Rails has almost 300 forks on GitHub alone. In fact, every time you `git clone` Rails you fork it.
If someone has stopped maintaining a small library, you can fork it and take over. It's now your library. Others can pull down your changes and watch your development.
If you don't like the direction someone is taking their library, you can fork it and head a new direction. And the two tracks can live in harmony. You can even take changes you do like from the original library and merge them into yours with ease.
These things happen all the time and are possible with a DVCS because of the opinions (or rather, lack of opinions) present in software like Git. Yes, you can add this stuff to Subversion - add offline committing, use shas instead of revision #s, enable inline branching - but as soon as you do Subversion becomes a DVCS.
For me, it's always been about the social aspect of DVCS. That is the interesting part. The technical awesomeness is icing on the cake.
Most of the time when I hear about pains of DVCS, it is when they are attempting to use it in a non-distributed way - without first having learned how to use the framework.
Learning git or hg as cvs/svn++ is REALLY bad. I've personally lived through Flock using hg for several months only to abandon it for SVN (hg was version 0.6 and would eat our commits...) I've also had to help friends at companies who jumped on git without knowing how to use it, and hearing horror stories about everyone rebasing/rewriting history combined with a central repo.
Honestly it makes me not promote git as much since I don't want to deal with the "svn++" mentality.
Yes, Rails still uses a 'central' development model. But it's trivial for me to fork Rails then track development, add my own features, fix bugs, or go my own route with a personal or corporate version of the framework. Many people do this. Rails has almost 300 forks on GitHub alone. In fact, every time you `git clone` Rails you fork it.
If someone has stopped maintaining a small library, you can fork it and take over. It's now your library. Others can pull down your changes and watch your development.
If you don't like the direction someone is taking their library, you can fork it and head a new direction. And the two tracks can live in harmony. You can even take changes you do like from the original library and merge them into yours with ease.
These things happen all the time and are possible with a DVCS because of the opinions (or rather, lack of opinions) present in software like Git. Yes, you can add this stuff to Subversion - add offline committing, use shas instead of revision #s, enable inline branching - but as soon as you do Subversion becomes a DVCS.
For me, it's always been about the social aspect of DVCS. That is the interesting part. The technical awesomeness is icing on the cake.