Joel Spolsky expounds on the virtues of distributed version control

Not one day after I decided to unsubscribe from joelonsoftware... one of the first blogs I started reading regularly, he came up with a beauty right after announcing he was "retired" from blogging.  You can read his thoughts here. 

By the way, am I the only one who thinks Joel's new puppy looks a little like Joel?

I'm no fan of geek-worship.  There are a bunch of geeks out there who seriously worship other geeks and there are whole churches following the likes of Joel Spolsky and Matt Raible around.  The point is, I don't think that just because Joel Spolsky or Matt Raible say something that it becomes an indisputable law... and I don't think the fact that Joel Spolsky says distributed version control is here to stay means it is.

However, I have to say I agree with him.  Distributed version control has moved from the fringe to one that is more and more accepted by the corporate world.  The thing I don't agree with is, I don't think the world thinks in versions without thinking of change sets.  I don't think it is such a major paradigm shift of "thinking in versions" vs "thinking in changesets". 

Even if you "think in versions", you are only doing so because you are interested in the changes that come with that version.  Shifting your thinking to "Joe's version" or "Mike's version" is really not that different.  Also, ignoring change sets is not really something people on teams can do forever because eventually everyone's change set becomes a released product and all the change sets end up merged together anyway.  The sooner you can do that and debug the issues, the better.

What a change to a distributed system does is change the workflow.  Take an example where two developers, Joe and Mary, are working on web services.  Joe is working on the producer, Mary is working on the consumer.  Since the producer does not yet exist in source control, Mary has nothing to test against but her unit tests.  That works while she's developing functionality, but eventually she will need to test the integration.  Lets say Joe isn't done with the producer yet, but he has enough done that Mary could do some stub testing.  Joe checks his code into source control.  At that point, if a build was done for QA, there would be broken functionality in the build.  No one has really tested that this code works with a consumer, and admittedly, it doesn't actually do anything yet but provide Mary a way to test her code.

In a distributed world, Joe and Mary can easily work together by taking changes from each other and then, when the final product is complete and working, they can commit the changes to the build branch without releasing anything that is not working.

That, in my mind, is the benefit in the corporate world where large development teams have individuals concurrently working on small, inter-related pieces of functionality.

While I can't say I would rather switch to programming in C++ than go back to the world of centralized version control, the virtues of it are a good addition to any development team.  As we speak, my team is experimenting with distributed version control using Bazaar.  The details of that will follow here at some point when our experiment is complete.

Related articles by Zemanta

• An Intro to Distributed Version Control (zef.me)