Possible Duplicates:
Why is git better than Subversion?
I've already read a lot (not enough to get the perfect picture though) about versioning systems, and the obvious conclusion is that GIT is simply the best. Or Bazaar maybe. Or Mercurial. But if so it was, then nobody would be using SVN, but they still do. Why? I myself have no own opinion on what v.c.s. is generally the best yet because of lack of experience with them. Could you share your thoughts?
Go through this http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/
People are still using Subversion because it's designed using the first paradigm to come for version control systems (centralized). Switching to distributed (and change-based instead of version-based) can take some time to get accustomed to (as you can see in Joel's experience), and so many teams decide not to use it due to resistance to change.
Mercurial tooling is quite mature, comparable to SVN in my opinion.
Talking about the company I work for — the biggest reason for using SVN is being able to keep huge, proprietary format, binary files under version control. Specifically, libraries of thousands of CAD files. In this instance, it does make sense to have the VCS be file-based like SVN is, rather than textual-information-based like Git.
Putting aside whether or not you can do shallow "checkouts" with Git, or how well it stores binary data, the fact is that it's designed to track lines of textual information floating around a tree of source code. As well as it does this, that model is not suited to tracking libraries of binary data.
Honestly though, that's about the only solid reason I would recommend it :P
SVN is established and mature, with equally mature tooling.
While svn is established/mature, I have to admit, Kenji Kina is right: it's living in the past with a version control model that is outdated. I've only used svn, but after reading/watching Linus and Joel talk about DVCS, it sounds like a brilliant idea. I think Perforce does something similar.
This doesn't mean svn is bad (it works rather well!), but it is easier to manage your code and have more frequent commits with a DVCS. Because if you break something, its easy to undo. If you branch, its easy to merge. In general, they fixed a lot of the major headaches most have with Subversion.
If you've never used another version control system before, and are cool with deploying it yourself, and write code (and not documents or pictures or things that you don't need textual stuff/diffing for), do yourself a favor and look into DVCS. Then you won't need to be re-educated.
Subversion has an advantage when a repository contains lots of binary data, which don't delta-compress well. A Subversion checkout grabs the head only, but git clones the entire history, which can weigh in at multiple gigabytes. Yes, this is nice for airplane mode, but fetching the initial clone can take hours.