First of all, use git for version control. It is modern, works great and the majority of developers are either comfortable in using it or want to start using it.
Its a pain in the arse to learn, overcomplicated for 90% of the cases it is used in. How many people actually need a distributed version control."
(I use Git. It is powerful and useful, but the justification for using it in the article isn't really great. No mention of Mercurial or other version control systems).
The fact of the matter is that love it or hate it, Git is now the most widely used VCS on the market in corporate settings (see e.g. http://www.itjobswatch.co.uk/). More importantly though, it is also the de facto standard for version control -- the lingua franca of source code management, communication and collaboration. Subversion and TFS still have significant market share, but everything else has pretty much fallen off a cliff in the past couple of years.
Also, many of Git's most powerful features have nothing to do with being distributed. Easy branching and merging, private versioning, bisect, rewritable changesets, stash, and the ability to cherry-pick individual changes within a file to commit, back out or stash could all theoretically be built into a centralised system.
The benefit of standardizing on a tool that is "good enough" is worth it imo. Learning git is easier than learning svn, darcs, hg, perforce and git and juggling between them when you want to submit patches to open source projects or get new clients.
The world's inconsistent internet connections are a great reason to require distributed version control. I'm often trying to work from a location without a reliable connection to the internet, be it a plane, train or bus, a coffee shop with spotty internet or a meetup. Requiring a connection to a server kills productivity in those situations.
Perhaps there is something to be said for Mercurial, but unless you were previously on Subversion it's certainly not that it's easy to learn.
Your imagination ignores days where you WFH (like I am right now), it ignores remote workers, it ignores work while traveling, it ignores outsourcing, it ignores open source development.
But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be. That's why it's good.
He's not ignoring anything; he said non-distributed would handle 90% of use cases and that's probably somewhat true. Saying hey I'm one of those 10% isn't a rebuttal to what he said.
I definitely want to see some substantiation that everything I just enumerated is less than 10% of software development, by whatever metrics he wants: number of projects, lines of code, whatever.
Those things don't require distributed source control; they simply require remote access. Substantiation simply isn't necessary, you haven't given scenarios that demand distribution and you can't, because honestly there aren't any. Distributed source control is a preference, a style, not a necessity. Central repositories with remote access handle all of those use cases. Other than perhaps the Linux kernel, there's very little software that can't be written just fine with remote works and centralized repositories.
- Central repositories handle me working from a coffee shop with spotty wi-fi. No, I am not going to wait to commit until I get home, because I want a set of commits as I go so I can revert if I screw up.
- Central repositories handle me working on a plane. Same thing.
- Central repositories handle your Chinese subsidiary being constrained to a slow and spotty pipe (they actually exported our tree with git-svn and used git on their end--this was at a NASDAQ company, it's not like anyone was cheaping out, it was the best available).
That you are willing to work around the deficiencies of centralization does not mean they are not deficient. Don't be ridiculous.
My bad, I was overly huperbolic; of course there are situations situations in which distributed is clearly better. I use git. But I'd say those easily fall in the small minority of situations. Most of the time for most programmers I think, internet access is not an issue.
No worries. But I'd turn that around: is it not an issue because it's not an issue, or is it not an issue because we are trained to alleviate it? 'Cause I enjoy working from the park, too, and I wouldn't even want to trust tethered 4G to not be a pain in my ass while doing it.
The park... me thinks you live in a bubble and don't know what the average developer day is; believe it or not, most developers don't use git or any kind of distributed source control because most developers aren't working for cool startup's in the valley or on open source projects. Most developers are banging out Java and .Net apps for corporations using some form of centralized version control and not being able to work from 4G in the park isn't a problem they ever face.
First of all, use git for version control. It is modern, works great and the majority of developers are either comfortable in using it or want to start using it.
Its a pain in the arse to learn, overcomplicated for 90% of the cases it is used in. How many people actually need a distributed version control."
(I use Git. It is powerful and useful, but the justification for using it in the article isn't really great. No mention of Mercurial or other version control systems).