The change-over to distributed Source-code control seems to be only a matter of time. Dispite the hype subversion makes many jobs harder, it might help with renaming files but it doesn't. The battle has really already been won my distributed systems in many organisations. There are a few factors that have prevented wholesale takup of distributed source-code control:
- Maturity of tools. Many of the existing systems exist as extended research projects. They are scripts on top of other systems written in perl or python. Where they might work very well they are slow.
- Tool Support: In some organisations there are multiple platforms and the availability of integration into tools like IDEs affects the decision. Taking Eclipse as an example, most Distributed Source Control systems have earily or no plugin available.
- Unreliable: Some of the implementations are unreliable and inferior to others.
- Culture: People are sure how to implement their development environment with their existing tools. Often it is up and working and it is unclear how to change this to a distributed model.
The technical points of these are slowly disappearing, and it is likely that this year major projects will move their Source Control over to a distributed technique following the trend that the large open-source projects like the Linux Kernel and Mozilla are setting--- which are following some of the more mature programs (well in the Linux case--- it's home grown solution: git).
Culture is the easiest change as once these system are tried and solutions for Releasing are relealised nobody looks back.