好的技术问题通常会引出技术专家们依据经验得出的深层次的观点。但对于这样的问题的答案也很容易演变成完全基于个人喜好的情绪倾泄，而不是根据事实、标准和具体的专业知识。就比如本文的这个标题，如果你是一个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 并不仅仅是一个版本控制系统——它实际上是一个文件系统，它里面有很多的拓扑学知识来支持你如何在不同的环境中架设代码仓库——并且没有一个统一的标准。 选择一个合适的拓扑结构就成了难题。 其它一些优势：
|
