Richard Fine has an excellent blog post discussing why it's time to stop using Subversion. I was struck by the similarities between his reasons for leaving SVN in the dust and mine:
- committing == publishing
- reliance on a central server
- filesystem operations
It's worth reading his comments on each, and I wondered if he and I ended up switching to the same VCS - and if so, whether we did so for the same reasons. Well, it turns out to be the case: Richard is now using Git, but was initially wary:
When I first heard about Git, I didn’t really get it. Distributed version control seemed like a really bad idea – who’s copy of the code is authoritative? If bugs are logged against a particular build, how do you track down the code that was used to create it? The loss of things like sequential revision numbers seemed like a big drawback. And branching wasn’t something I ever used in Subversion, so I didn’t see why I should care about it in Git.
When I first picked up Git, I didn't understand how a distributed system worked. As unhappy as I was with relying on a central Subversion server, I didn't see how exchanging patches between peers would work well, and I didn't understand how an authoritative repository emerged from the network of peers. Well, I've gotten over that, and the other misgivings Richard mentions. But there was one issue I had which he doesn't mention: Subversion lets you check out part of the source tree; Git doesn't.
In the past, this capability has been really useful for setting up MediaWiki, and I imagine it would work for other web applications as well where all you really need is the tree of files. This makes upgrading trivial - svn up and run an update script and you're done, typically.
Git explicitly does not support partial checkouts. Not only that, they don't apologize for it, and fail to understand the utility. I hope this has changed recently - it looks like there might have been some movement in that direction with "shallow clone" and "sparse checkout" but it isn't clear to me that these can do what SVN used to do for this use case.
Git's interface has vastly improved since the early days, but the interface isn't the only thing that needs improvement. Explicitly supporting common use cases should be a priority as well.