There are an almost uncountable number of posts and articles about this pseudo dichotomy; Subversion versus Git. This is not uncountable + 1.
Look, it’s not A versus B because A and B are not mutually exclusive. Subversion and Git take different approaches to version control. Both Subversion and Git can be usefully applied on the same project.
Git has a lot going for it. It provides a really great merge model. It allows developers to communicate their changes freely without a central repository. It allows developers to commit as many times as they like without polluting the main history. It encourages the use of branches. It provides the idea of temporarily stashing changes in order to work on another version of code. I really like Git a lot.
Subversion provides centralised control (authentication/authorisation to access). All an enterprises code is centrally held. Developers hold only what they need to be working on (not the whole history of the product spread amongst all your developers). It provides a sound and relatively simple branching model that, used properly, simplifies history tracking. I like Subversion a lot.
Git can lead to some terrible histories and horrible merge overheads if not used with care (people forget that merges may be helped a lot by Git, but they still need to be done—and a lot of them under some setups—and each one is an overhead, the cost is just ‘lost’ by being distributed). It is easy, without good discipline, to create an intractable mess with Git (think rebase and squash with other people’s partial changes in the source branch, or push and then modification of public commits). I dread using Git.
Subversion is heavily centralised, there is a tight dependency between users and the central repository. Branch and merge are more rigidly employed in Subversion. Merging can be a monumental pain unless you are disciplined in your branch/merge strategy. Developer to developer communication of changes are more strictly limited and involve either circumventing the version control system or going through the central authority. Developers cannot easily stash changes (although this is being addressed with the upcoming ‘shelving’ feature), cannot work disconnected as easily, cannot create temporary branches easily. I dread using Subversion.
Quite apart from developer’s preference there are broader considerations. Does the organisation have specific requirements (like security)? Is a mandated central solution required in order to reduce training or administration overhead across the organisation? Is a particular solution better because it integrates well with the rest of the organisation’s development infrastructure? And the list goes on…
So, which would I choose for your next project?
Well, that depends on what your next project or organisation needs.
It’s fundamentally foolish to say, ‘X rocks hard. You should use it on your project’, without knowing the circumstances of the project. That’s like saying, ‘this hammer is a great tools. You should use it on your project.’ What if your project is screwing together a flat-pack bed? I would suggest that, perhaps, a hammer is not you best tool on this project. In the same way, your project may be harmed by using the wrong version control tool. There is no one-size-fits-all solution.
Sure, Git may be better than Subversion on your project. Subversion may be better that Git on your project. Perhaps using both Git and Subversion on you project will be the best solution. Figure out what your project needs, then find an appropriate tool. (How? One excellent way of setting up a project’s version control system is to employ someone with experience in tool selection and commissioning —hint.)