好的技术问题通常会引出技术专家们依据经验得出的深层次的观点。但对于这样的问题的答案也很容易演变成完全基于个人喜好的情绪倾泄，而不是根据事实、标准和具体的专业知识。就比如本文的这个标题，如果你是一个SVN的坚定支持者，你完全可以把这句话反过来问。
我使用SVN有5年的历史了，而且现在在公司里仍然是使用SVN。但是大概在3年前，我的所有个人项目都已经迁移到了git(gitHub)上。我能想出很多git优于subversion的地方，大部分是体现在分布式优于集中式的特征上，但如果你让我说出任何SVN分过来胜过git的地方，我竟一时想不出来一个。但这就能说明git完胜SVN吗？
事实当然不是这样，就像是Windows和Linux，你不能说这个一定就比那个好。最近在stackexchange的讨论让我学习了不少。先举个简单的例子证明有些地方你只能用SVN而不能用git。谷歌的搜索排名算法，就不能放到分布式开放的代码库了。这种情况下SVN的集中式管理就是不二选择。下面就来条理的看看Subversion在哪些环境下比git更适用。
Subversion是集中式管理的数据仓库
虽然速度快和多副本等git分布式数据仓库显而易见的好处吸引了很多人的喜爱，但在很多情况下，一个集中式的数据仓库却是更合适的。例如，如果你有一些核心代码想只允许部分人能访问，把它放到git里必然是你不希望的。很多的企业都是将它们的代码集中管理的，我猜，所有(重要)政府项目估计都使用的是集中式数据仓库的版本控制系统。
Subversion的理念符合常规思维
这是说，很多人(特别是管理者或老板)对版本号有一种习惯的认识，把开发视作一种按时间的线性发展轨迹，这在他们脑子里根深蒂固。并不是找借口，Git的随意性并不是很容易去理解，你也许注意到了，任何一本关于Git的书都会在第一章第一节告诉你要抛弃脑子里所有的传统观念，重新认识。
Subversion只提供一种途径，没有第二选择
SVN是一个版本控制系统，它只提供一种方式做这些，每个人都使用相同的方法。就是这样。这使得你将代码从SVN迁移到其它集中式管理的VCS或从其它集中式管理的VCS迁进来变得很容易。Git并不仅仅是一个版本控制系统——它实际上是一个文件系统，它里面有很多的拓扑学知识来支持你如何在不同的环境中架设代码仓库——并且没有一个统一的标准。选择一个合适的拓扑结构就成了难题。
其它一些优势：
- SVN支持空目录
- SVN有更好的Windows平台支持
- SVN可以check out/clone一个子树(sub-tree)
- SVN支持特权访问控制svn lock，在处理很难合并的文件时非常有用
- SVN支持二进制文件，更容易处理大文件(不需要把老版本拷来拷去)
- 提交文件相对简单，因为没有pull/push操作，本地修改通过svn update自动的执行了同步代码的功能。