By webmink on Jul 02, 2007
I admit it's been a while since I had to use a source code management system for real - over 10 years in fact. So I was intrigued to read what Stephen O'Grady recently published about distributed source code management (DSCM) in one of his signature Q&As. He makes a number of interesting observations, but I was interested by the omission of a whole thread of analysis around the assertion Mark Shuttleworth makes that merging is the key to source code management.
Sun has a long history with DSCM, and the tool used internally by many teams (Teamware) is in fact the predecessor of Bitkeeper written by the same author, Larry McVoy. The development of both Solaris and the Java platform uses Teamware and the distributed approach is a fundamental factor in the development culture of both products.
When we open sourced Solaris and seeded the OpenSolaris community, it was very much an act of opening an existing distributed community to public participation rather than the creation of a new community. That's why it was obvious to that community to want a DSCM to maintain the source code in OpenSolaris. Since Teamware was (and is) a proprietary tool, they selected an open source system for community use.
Stephen seems to suggest that in some way centralised SCM like Subversion is a natural choice for open source, but I would suggest that needs more thought. A DSCM is in some ways a group of inter-related CSCMs with added capabilities that reflect the nature of a diverse ecosystem. Yes, a team of developers needs a source code management system. But an ecosystem - with upstream builds and downstream distros, with multiple platform versions, with experimental features - also needs to be able to handle the reconciliation of changes as easily as possible.
So I'd suggest that while CSCMs may be ideal for the team-based development found in smaller open source projects, DSCM is for ecosystems and thus is the natural choice for open source communities. In other words, it's a trend.