In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
others don't have directories under revision control, and so on. How is such information to be passed between tools if we don't agree on what the information is? How can we gather common metrics across tools, or share development across SCM platforms?
I'm just as much at fault as the next guy. I haven't demanded that the SCM industry produce standards for information interchange. In spite of trying to work with non-standards such as Microsoft's unofficial SCC API, or the Eclipse platform, I have not tried to force the issue on anyone. Instead, I've taken my own views, formed somewhat by the rest of the industry perhaps, and have marched down the road in a manner that I thought was best. So where to go from here?
Unfortunately, the CM technology space spans several generations, from 1st generation tools dating back to the 1970's to the odd 3rd generation tool (and, perhaps, even a 4G CM tool). Each tool tends to have a specific feature or feature set that helps it to stand out, but is perhaps very different from other tools in the industry. Trying to reach some consensus on CM standards is a challenge.
What makes things even more difficult is that, with the variety of CM processes, advanced CM tools sometimes act as CM toolkits, where you can not only adjust the existing processes, but even add in your own new processes, schema and user interfaces.
A de facto Standard?
Some say that subversion or other CM tools will evolve into a standard, but I don't buy it. SCCS was almost a de facto standard back in the 1970's and perhaps 1980's. It just didn't have the legs to make it beyond that, though. The same happened with CVS, which started gaining ground, but eventually gave way to SVN. Many people love SVN, but for me, it's a couple of generations behind.
It's not likely that a de facto CM tool will emerge unless a vendor of a very advanced tool goes open source. Even then, there are too many other considerations that make a standard much more than just the tools that are used.
This could be a promising avenue to pursue, but there are significant problems here. We might all agree that change packages are a good thing, but will we agree on viable branching patterns? Will we agree on single Main