SVN is not dead at all. It’s is still in extremely wide use, and it’s not going anywhere anytime soon. SVN is much simpler to use than distributed version control, especially if you’re not actually running a distributed project that needs distributed version control.

If you only have one central repository (which is all your company will need if they’re still small enough to get by without source control so far), it’s much simpler to use SVN to interact with it. For example, with SVN you can pull changes from the repository, or commit your local changes to it, with a single operation, whereas HG and Git require two or three steps to do the equivalent work.

And with the recent revisions, SVN has fixed a lot of the performance issues that made people prefer HG and Git. It’s significantly faster now than it was a couple years ago, and at this point, there’s really no good reason to look at HG or Git for your project unless you actually need the advanced features of distributed version control.

Client tooling hasn’t been mentioned yet. You can certainly do everything with a command line script but having GUI integration can be a real productivity boost.

We work mostly with Visual Studio; integration into the IDE is definitely better with SVN than with Git right now. This may change in the future, but I’d certainly weigh this into your decision just as much as the version control functions.

Just like everything else, a version control system isn’t a goal in itself, just a tool to get you where you’re going. Pick the one that’s going to get you there fastest based on your situation.

I’m a Git fan. Recently I had to admit that one of the downsides of Git is that it identifies versions with hashes as opposite to svn’s release numbers. The release number can be easier passed on by phone or something like that.

And that’s the only pro I can imagine. If you really want to rely on that feature you can have it in a distributed and/or centralized VCS Bazaar. In Git there are tags that can serve the purpose.

Anyway I just couldn’t imagine developing without quick branch switching, and stashing. These two features alone beat SVN, where as far I remember the same task required creating and checking out a whole tree into separate directories to achieve the same goal.

Those so called “advanced features of distributed version control” come with the time, and you don’t have to learn them at the very beginning. Don’t be scared of them. They are here to help you, not to get in the way. And there’s no problem to set up a central repository for a DVCS.

“If you have a task that can be done on six hours, it is better to write a tool that does it in 20 minutes, even when creating the tool takes six hours?”

Distributed Version control is a different beast to tackle. It requires substantial learning for each developer. If you have the buffer to accommodate the learning process for each developer, you should move to a good distributed version control system. Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.

Distributed Version Control seems to be an eventuality. It is here to stay for a very long time, it is better that we adapt to it sooner than later. I remember the same discussion when SVN was new and people were used to CVS, lots of arguments were given for not using SVN, but eventually SVN became the most popular version control system.

If the company is well established with a lot of source code in the existing version control system, moving to a new system is a big task, but if the company is small or starting up, moving to a new version control is very easy. But if you stick to an older version control (in a new setup) you will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration anyway.

I have seen a lot of pro SVN comments, but all of them tend to be of the nature “SVN is not bad” rather than “SVN is better”. So I would strongly recommend that you choose a Distributed Version Control (such as Git) for your project.

EDIT
Advantages of GIT over SVN

1. No dedicated server required Actually, both can be used w/o a server.
2. Can continue development even without a network connection.
3. Branch management is much easier.
4. Better support from CI tools such as Bamboo

Someone mentioned tooling (for visual studio) as a reason to stick to SVN. http://gitscc.codeplex.com/ provides GIT support for Visual Studio.

With SVN you can easily checkout parts of a repository down to the folder level, whereas with git, you get the whole repository, including all the history.

Depending on the situation this may have some advantages for SVN

(this also has some big drawbacks such as the hidden “.svn” garbage all the way up your folder tree).

would there be any specific reason to use Subversion those days

Apart from tooling support in IDEs (which I don’t use) – not really, no. Of course SVN may be more familiar but that’s about the only reason, and I’ve found both Hg and Git very easy (and very fast) to learn.

Yes, there are all those complex guides out there which describe how Git is trivial once you understand that branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.¹

I don’t understand that. But you know what? It doesn’t matter. You don’t need to know any of that stuff to use Git.

For the most part, Git and Hg are easy to use and they have definitive advantages over SVN. The elephant in the room is of course branching: branches just work in Git and Hg. By contrast, in SVN they are painful at best and broken at worst (merging multiple heads).

Of course you can still use SVN. You can also still use Windows XP. However, the majority of users who have tried both agree that one of the alternatives is vastly superior.

¹ Yes I get that this is a joke. I think.