I don't really get that part, at least not with the way I use svn. I branch, I tag and I use patch sets, which have some similarity to changes. I read this bit

I don't really get that part, at least not with the way I use svn. I branch, I tag and I use patch sets, which have some similarity to changes. I read this bit http://hginit.com/02.html http://hginit.com/02.html from Joel's Mercurical intro, and it sounds a lot like how I use svn, except that the branches are on the server, so they are probably a little slower, with the positive tradeoff of being available to my team. The other bonus with dvcs is having local history without doing pushes, which I think is a bigger selling point (although I get something similar from my IDE). I generally hew to the extreme programming view of branching and continuous integration. Push early and push often. Browsing github, I seem to find a preponderance of projects where the branches are never push-ed back to a master copy. No matter what tool you are using, branches can introduce semantic changes that are hard to merge. To sum, DVCS not that big of a deal for the way many people already use CVCS, when you end up working with a centralized copy anyway.