On the Shoulders of Ancestors
I’ve been involved with Mercurial for only a brief period of time but I’m loving every moment of it. When I chose Mercurial over git, I did so despite the latter’s royal (Linux) bloodlines. I haven’t regretted my choice at all, and I’m more and more convinced that it was the good one as I’ve become involved with the project more.
But git and Mercurial have something in common: their shared dislike of Subversion. It’s much less prevalent in the Mercurial camp, but Torvalds’ introductory git talk at Google did pretty much massacre Subversion. Joel Spolsky called Subversion a path to brain damage.
Of course, these people did something about it. Torvalds wrote git, Spolsky released Kiln and sponsored some Mercurial development in the process. But it’s always worth remembering that without stuff like SVN, we might not be where we are today. Many tools, not just version control systems, come into being as a response to what users of existing systems find to be notable shortcomings. And even though it’s time to ditch Subversion, maybe we can quiet down on the hate-talk. Subversion’s original goal was to be a “compelling replacement for CVS”, or CVS done right; git and Mercurial are both further improvements. Guess what, we’re probably going to see someone try to replace them as well.
All software tools attempt to solve a problem. They reflect workflows, and are optimized for certain use-cases. Centralized version control made sense in companies because of similarities to how those organizations are structured. In those environments people tend to be assigned specific tasks to work on, so concurrent access to any one resource is reduced. It’s not necessarily the better way to go about development, but it’s the workflow that dictated the tools, not the other way around.
So before you switch to Mercurial (or git), please take a moment of silence for those fallen. Be happy those tools existed in one form or another, think little of the pain they caused, and focus on what the existing tools do well, and what they don’t. Often, we can improve what we have and work around limitations (which is why Subversion lasted this long, why people write extensions to existing tools etc) and sometimes we need to throw it all out and do it anew.
