Slow and steady wins the race
Every now and then I’ll have a conversation with a developer and the topic of “Why doesn’t everyone switch to X?” comes up. For X, substitute any of the following “new” things: version control, language, database, OS, methodology, pattern. It has taken me a while, but I have learned through experience that just because something is new, it doesn’t mean you should jump into it. A lot of people don’t realize the value that an established process/technology provides, that stability can be priceless. For example, people who jumped whole-hog into JavaFX are probably starting to regret that choice. Now having said that, there is a break even point, the older a project is, the more one should look at specific fixes for specific problems. Switching from Java to .NET? Not important. Switching from COBOL to Java/.NET/Ruby? Important. Changing as few variables at one time as possible? Vitally important! Version Control really seems to be finally getting the attention it deserves lately and that is a great thing. Disciplined open source projects have been setting a great example for developers and businesses alike for some time. As a result, a lot of them are using “older” technologies like CVS. A few years ago there was a flood of people breaking away from CVS to use Subversion, and these days there’s a push to go to distributed version control solutions like Git or Mercurial. This great article talks about one group who made that decision and the work they did to ensure their history (and build-able version of older releases) were ported over into the brave new world of Git. I am very impressed with the level of maturity the project leaders showed with that conversion: They did not just drink the git-workflow kool-aide, instead they decided to change only one thing: the version control system.
Side note : One of the major turn offs for me about the Git community was their instance on adopting their workflow model when using the git tool. While I welcome new points of view and ideas, a while ago it seemed like it was “git’s way or the highway” when it came to using that system. Mercurial on the other hand seemed a little more open to the typical svn/cvs way of doing development. That is one of the reasons why I personally chose to work with Mercurial. In the time since then my personal workflow has changed a little bit to be more like the DVCS approach. In time I might become less of a svn developer and more of a DVCS developer. Having said that, I still don’t care for the Git staging area.
My hat is off to them for keeping their project under their control while modernizing a significant piece of infrastructure. My hope is that Postgres will stand as an example of how to grow without starting over. Once the developers, testers, users, and other stakeholders get used to the new version control system, then they can make the next move (whatever that may be). I think that down the road a few years this will be seen as an important decision by the project leadership, in the event of a bug being found, they will be able to look at the history and see when it entered the system and at the same time be able to reap the benefits of the DVCS revolution.tags: