Wow. I had no idea that subversion was so recent; Subversion 1.0 was only released in 2004. So it became the de-facto standard for scm (and introduced thousands of developers like me to scm for the first time) in only a couple of short years. That’s just amazing.
So I guess the rise of distributed version control hasn’t been as meteoric as I thought, and certainly less meteoric than the rise of the software that many people see it replacing. Linus Torvalds wrote Git back in April 2005
Just watched a great video of [Linus Torvalds presenting on Git at a Google Talk in 2007](http://www.youtube.com/watch?v=4XpnKHJAok8); he’s smug and unbearably rude but very funny in it. A very likeable and compelling presenter.
I found [this post by the creator of Subversion](http://blog.red-bean.com/sussman/?p=79) minutes after completing the video, which is where I found the background to svn that I hadn’t known and also these salient points about how Subversion unexpectedly found its niche and massive acceptance in the corporate world, and how distributed version control sits uneasily at best within that world
Corporations are inherently centralized entities. Not only is their power-structure centralized, but their shared resources are centralized as well.
Managers don’t want 20 different private forks of a codebase; they want one codebase that they can monitor all activity on.
Cloning a repository is bad for corporate security. Most corporations have an absolute need for access control on their code; sensitive intellectual property in specific parts of the repository is only readable/writeable by certain teams. No DVCS is able to provide fine-grained access control; the entire code history is sitting on local disk.
Cloning is often unscalable for corporations. Many companies have huge codebases — repositories which are dozens or even hundreds of gigabytes in size. When a new developer starts out, it’s simply a waste of time (and disk space) to clone a repository that big.
Again, I repeat the irony: Subversion was designed for open source geeks, but the reality is that it’s become much more of a “home run”for corporate development.
I think these are great points, and ones that should give anyone doing the job I used to do pause for thought. But on balance, I think the key point I’m left with is one of those made by Linus Torvalds in his presentation at Google. Subversion was designed to make branching quick and easy, but who cares? It’s merging that matters. Even Subversion 1.5, which shipped well after Torvalds was speaking on this occasion, only allows you to merge kind of easily back into the trunk once. It’s a long way from the ease of merging that Git and Mercurial offer. That really matters.
Also, the key reason why distributed source control is great for teams is that it frees individual developers to commit as much and as often as they wish – in other words to get the proper benefit from using source control – without inadvertently pushing their changes out to everyone else, until they are ready for other people to see it.
Polsonby 