[Update:

I have received a lot of attention. Thanks for that. But obviously not everybody has detected the unobtrusive irony this article might contain...

So please reread this article one more time before you:

  • Link this article to your Subversion-Blog
  • Try to convert me to Git
  • Use the arguments in a real discussion

But the reactions I received, prove that I have mimicked some *real* opinions very well. And that really makes me sad...]

There are many blog posts out there that try tell you why Git is better than Subversion. But very few that tell you why Subversion is better that Git. As expected: You don’t have to state the obvious…

1. It is industry standard

Subversion is more widely spread and better known.

And it is a good idea for every business to rely on the “industry standard”. Therefore it is strongly recommended to use CVS (the real industry standard) or at least Subversion. But please stay with version 1.4. That one is well tested. And the new stuff probably has many bugs that just wait to purge your repository (and all backups).

Prove: Just compare the frequency of releases

The last CVS releases have been 1.11.22 on 2006-06-09 and 1.11.23 on 2008-05-08.
Subversion releases a new version about every two or three months (1.6.6 on 10/22/2009, 1.6.5 on 08/22/2009).
But Git: They release new versions every few days! They have so many bugs and so few features that they are forced to release even the smallest improvements immediately…

Remember: Fewer releases represent greater stability and more features.

2. Central Repository

Subversion has a central repository. That is what everybody wants. Every manager wants to know where the code lives. With subversion you can take his hand, guide him to the server room and point to the server.
That is what managers want.
That fancy “everybody has the complete repository” is not a work flow – it is communism…

Distributed Version Control System”

That sounds like some alternative to BitTorrent. I don’t support pirating!

3. Subversion is easy to use

The developers I have met so far, don’t understand complicated (read “command line”) tools. I don’t have to talk about web designers or sales people here…

Subversion has a nice UI (Tortoise SVN). The developers can use that UI. And they don’t have to understand the complex mechanisms of VCS. Just a click here and there is enough (see “Branches are evil” for more details).

If a problem occurs:

4. Subversion supports a single strategy that solves all problems

And if any problems occurs, those can easily be solved in Subversion: Just copy your modified files away, make a clean checkout and merge the files back manually.

That is all. No fiddling with branches, command line and such stuff.

5. Branches are evil!

Forget about creating branches (or – even more dangerous – merging). Branches are just useless and a sign that your team is not coordinated well.

Have to do critical stuff on the trunk (e.g. performing a release)? Just shout to your colleagues to stay away from the repository. Development may continue locally. And if the things take a little longer – no problem – the bigger their commits are, the better.

Maintenance branches? Come on. Have you ever seen us releasing a service release? And if really necessary: The forward-looking developer keeps a directory on his hard drive containing the sources the release has been build from.

6. Empty directories may be added

I really love organization. And I hate one thing: Anarchism. Anarchism and communism. Okay, I hate two things: Anarchism and communism. And bleeding edge…

And Subversion allows me to create a good and clean and complex directory structure. And commit it. And then check it out again. The directory structures I create usually are so helpful that everybody *must* see them immediately – just as inspiration.

7. The help is clear(er) and *much* shorter

Just compare the help pages for “svn log” and “git log“.

While Subversion just needs one page to document all features, the git documentation is insane long… Git is much more complicated. Even such a simple command needs hours to just read the documentation.

I’d go as far and say, that it is impossible to use Git without professional training of at least several days. And that is the hole point of that OpenSource/communism stuff: They try to cheat you to book expensive training…

8. Supports file locking

Do you miss the times of VSS, too?

I really hate that situation: I try to commit and have to notice that someone else has changed the file I worked on. This is ridiculous. Why should a colleague be allowed to change a file, *I* am working on?

So Git guys: First solve the locking issue and then come back.

9. Expandable keywords

I really love expandable keywords. In the old CVS days that has been my favourite feature. Okay, I don’t have a real use case, but I love to see the the magic happen.

10. Merges are forced immediately

Yeah. The killer feature of subversion.

I have to admit that maybe file locking is not the solution for every case. But at least each developer has to be forced to merge all changes before he is allowed to commit.

I hate those guys that work all day long and then try to commit their changes just seconds before they leave. And – additionally – they are very focused when they merge changes to their uncommited work. Knowing that each step might destroy the work of several hours is a great motivation.

This feature often leads to check in races. The first commiter wins, the second one has to merge. And that is worth cash: Developers are motivated to work as fast as possible.

And one more thing I love: If you are leading the check-in race, you can keep your colleague merging for a long time. Commit – file has changed in repository – update – merge – trying to commit – file has changed in repository… I could do that all the day…

Conclusion: Subversion unifies a team

Disclaimer: I really like Subversion. I have used it for several years. And I know branching has been improved dramatically in version 1.5. So this post is not a rant about Subversion but instead about those people that refuse to take the next step. Those people that prefer CVS over SVN, SVN over any DCVS and so on…