Centralized And Distributed VCS

Andy Singleton has point when he says that Subversion still has its place. Or that centralized VCSs are not losing against the distributed VCSs. While I agree that Subversion is not going to fade away, I wonder if the ease of use is the best argument for it. I have heard the argument about geographically distributed teams as well. But I feel it is more about distribution of the programming tasks that determines the suitability.

A team, where programmers share tasks, is more productive with Subversion. A centralized repository is necessary in such cases to integrate the code everyday. One of the best practices in such cases is that every programmer checks the code in the centralized repository at least once a day.

A team, where programmers take up separate component/module tasks and are self-reliant in terms of their need for programming and testing, works well with a distributed VCS. Here, the ease of creating branches and maintaining a local copy instead of a centralized repository helps in isolating your code from the rest while it is in development.

To an extent it also depends on the way the team is managed. Some feel that by seeing the code integrated everyday they have more control over the tasks and progress of the project. And I think this traditional model of software project development calls from the traditional centralized repository.

A distributed VCS lets you isolate your code, while in development, and merge it back when it is ready. Which is why more and more open source projects have started using it.

It is more about the project management than anything else.