The B-List

Description

An entry published by James Bennett on July 28, 2008 , Part of the categories Misc and Programming . 55 comments posted. So, a few years ago all the cool kids were switching from CVS to Subversion. These days, all the cool kids are switching from Subversion to some form of distributed version control; git and Mercurial seem to be the ones with the largest market shares. This switch is being accompanied by a simply deafening amount of hype about DVCS and how it’s a revolutionary new paradigm and will completely change the way people work and… well, the usual stuff. Over the past few months I’ve tried out both of the popular DVCS tools: first I spent some time puzzling my way through git and realizing that, though I’m fond of wiring together five dozen things with baling twine and duct tape to create a Rube Goldberg monstrosity, I’m not yet ready to trust such a contraption with something like, oh, an important codebase. It works for Linus because he wrote it, and that’s great for him. But it isn’t for me. Then I tried out — and am still poking around with — Mercurial, which is on the whole a much friendlier and more humane tool. But all of this poking and prodding has left me with a couple of nagging questions about which I am intensely curious, so I’m going to write them up here and hope that someone smart can answer them for me. So, yeah, there’s a lot of hype about DVCS. And while I’m prepared to dismiss a lot of the hyperbole as being simply the sort of thing you get in these situations, there’s a lingering undercurrent of people suggesting that this is fundamentally different from how we’ve been doing things up until now. Which is kinda funny to me, because I look at why people get excited about DVCS and basically all I see are decent merging algorithms. If I had to guess, I’d say that 90% or more of the claimed benefits of DVCS really do boil down to “wow, it’s easy to merge stuff”. While it’s nice to have better merging than Subversion — and, really, what doesn’t have better merging than Subversion? — that doesn’t exactly make for a brave new world. The other big win people often claim for DVCS is offline commits. At first I was kind of puzzled as to why offline commits would be such a great feature, and then I saw that mostly, the hype around them was about having a nice little local revision log you could step through before sending your changes off somewhere else. So DVCS — as far as I can tell — is about better merging and offline commits. Which is a problem if you’re a DVCS advocate, because neither one of these seems to be intrinsic to the nature of distributed version control. Let’s take offline commit as an example. Suppose that a new feature gets added to Subversion, such that you can sit at your computer and edit files in your working copy, and when you’ve reached a logical stopping point you go and type something like: And suppose that this would make SVN record the current local changes and make a little local log entry. Then, when you were ready to start committing back to the repo, you could step through your waypoints and decide which ones you want and which ones you don’t.

Companies nearby