Unlike some others, I don’t get excited about source code management (SCM) systems, a.k.a, version control systems (VCS). Unless it’s your job to build such things, they’re a means to an end, not an end in themselves. For me, they’re much like circular saws: I’d better have one when I need it, and it had better work and work well.
I was reminded of that during some merging madness today. Nearly all of our team’s work is done in source code managed by a very good VCS, but a few files are outside that. We clashed on those files, so merging and managing them caused far more trouble than it should have.
So it brought source control out of my subconsciousness, and I thought about how different SCM approaches seem to have tracked right along with society’s philosophical trends. Consider:
– 70s – The Me Decade. The move from punch cards and shared readers to private online storage with checkout systems allowed each to “do his own thing” and “discover himself.” Folks started digging groovy things like SCCS and IDSS.
– 80s – The Mine Decade. Materialism rules, and he who dies owning the most files wins. The “personal computer decade” had folks keeping their files to themselves and brought us things like PVCS (“lock early, lock often, unlock never”), and ENVY (“that’s my class, you can’t release it!”). Gag me with a spoon!
– 90s – The Jam Decade. By the late 80s (even before Pearl Jam hit it big), this pessimistic locking thing started getting really old, and the collaborative “web decade” saw SCCS revived as RCS and then CVS. This had optimistic checkout as the default, and sharing and merging was expected. Continuous integration became cool, as developers could know wassup with their homeys. Word, dat’s phat!
– 00s – The Whatever Decade. Early in the decade, Subversion began to loosen things further. And soon, in postmodern fashion, everyone wanted his own version of the truth. New distributed version control systems (DVCS) like Git, Mercurial, and Monticello followed, elevating the old idea of a change set to a legitimate stream of development. This “truth depends on who you ask” approach was fast and flexible. That is, until integration/build time, when only one right way must prevail, and everyone must merge onto the narrow path. Often it would come down to trust: use the code from your sweet peeps, and ignore the n00bs.
So what will the 10s be known for in source control? I suspect DVCSes will continue to grow, led by ever more open source projects using them. Since this is becoming the “borrow and bailout decade”, perhaps we’ll see seamless integration with shared repositories of common code fragments. Check back in 2020 and I may write about it. That is, if I’m not so busy sawing away that I don’t really notice.