网上有很多关于 SVN 和 Git 的比较，但是大多数都是错误的，误解的。
国内外都没有一个好的 SVN 仓库，最近我自己做了一个出来，自认为是市面最好的：SVNBucket
但是引来了很多 Git 用户的不屑、瞧不起、过时
下面给大家列出来一些常见的误解和真相，虽然这并不能说明哪个系统更好，但是可以帮助你更好的理解两个系统之间的差异
1.同样的内容，Git 仓库远比 SVN 的小
错误：他们的存储机制实际上是一样的，所以相差非常小。例外的是二进制文件，SVN 反而会远比 Git 占用的小，因为 SVN 对二进制文件也能进行差异存储。
2.SVN 创建分支代价非常昂贵。
错误：很多人认为 SVN 创建分支是复制整套代码，代价很大。实际上从 1.0 版本开始，在 SVN 里创建分支的代价已经非常非常小，你可以任意创建分支来修复一个小 BUG 或者开发新的功能
3.合并分支时需要指定版本号范围
错误：这是一个过时的误解，从 1.5 开始就不需要手工指定合并的版本号范围了，更强大的是从 1.8 版本，还提供了自动合并的功能，大大方便了分支之间的代码合并。
4.SVN 需要在每个目录下都创建一个.svn 的目录
错误：从 1.7 版本开始，已经变为只在根目录存在.svn 目录了。
5.没有人再使用 SVN 了
错误：像 FreeBSD 和 LLVM 这种有名的开源项目都还在使用 SVN。实际上，有 47%的开源项目都在使用 SVN，然而使用 Git 的只有 38%。在公司层面就更多使用 SVN 的了，因为 SVN 是真正的标准企业级版本控制系统。
6.分布式的 Git 比集中式的 SVN 更优越
错误：他们是平等的。分布式只是实现版本控制的另外一种方法。集中式和分布式两种方法都有他们的正反两面，分布式或许适合某些人，但是他也带来了某些问题，比如：没有权限控制；每个人都需要完全 clone 整个仓库，没法像 SVN 可以只 checkout 需要的子目录；没法锁定文件等等问题
7.Git 很适合大项目，SVN 不行
错误：在 Git 里每个人都需要把整个仓库都 clone 下来，2G 的仓库或许没什么问题，但是到达几百 G 后呢？你需要 clone 几百 G 的内容，想想多可怕。有个经典的解决方式就是把 Git 仓库分为多个小的仓库，但是这就导致了其他几个问题：你需要管理多个仓库；破坏了原有项目的完整性；没法继续跟他们一起使用分支；
8.Git 适合大团队
错误：某些工作流适合使用 Git，但是某些情况适合使用 SVN
9.在 SVN 里，合并总是个痛苦的事
错误：SVN 已经能很好的处理合并和冲突，已经成为他很重要的一个功能特性。只有在分支里重命名了文件夹或者文件时会有这种情况，这是个历史遗留问题。
10.Git 有灵活强大的命令行操作
正确：Git 的设计初衷就是一套低级版本控制系统，允许高级用户通过命令玩一些黑科技，但是这并不安全，对初学者也不友好。Git 也因为没有良好的设计和混乱的命令受到了一些指责：这导致加长了学习曲线和大大增加了公司和团队的成本，特别是大型团队以及团队成员水平不一的情况。比如美术、策划、开发、这类人员，技术水平线不一。
11.Git 的历史记录不安全
正确：Git 的官方描述是“笨笨的内容跟踪”，它并不关心你整个仓库历史的完整性和精确性，这导致了重命名和 git rebase 这类操作很难跟踪他们的修改记录。相反 SVN 始终都可以精确的、完整的找到你需要的变动记录。
12.Git 无法提供细颗粒的权限控制
正确：因为 Git 分布式的原因，每个人都拥有完整的仓库代码，导致每个人都有完整权限看到所有的内容。虽然这样对于开源项目来说没什么，但是对于企业来说，这是不可接受的。相反，SVN 可以设置目录级别的权限控制，你可以设置他只读或者读写，而且非常适合大型项目。
13.Git 对二进制文件存储不友好
正确：Git 因为分布式原因，无法很好的处理二进制文件，他是基于复制模式来管理的，所以并不适合有很多二进制文件的项目，比如图片多的项目。
* 翻译来自：svnvsgit
* 如有翻译错误欢迎指正
* 希望给那些对 SVN 有误解的朋友一个参考。
* 理性的认识两个不同的工具，合适的使用不同的工具，他们之间没有谁更好，只有谁更合适。
