Skywind Inside

1）不可撤销，SVN 随便你怎么折腾都不会把仓库弄挂，git 的话就要小心了，即便你设置保护了 master，其他分支不小心也会给弄没了。

2）简单直观，不但美术容易使用，连行政和 HR 用 TortoiseSvn 的话，二十分钟就上手了，一说就懂。Git 的话，即便是程序员，想用好的话，不读下 pro git 之类的书，我看都着急。

3）权限细分到目录，可以每次只 update 一个小目录。

4）好管理，只要本地修改下 authz.ini 然后 commit，服务端 crontab 设置个脚本，自动让最新的 authz.ini 生效即可，一切权限变更都有记录。

5）不占空间，占用空间更小，提交一些美术资源都不用担心，比 git 占用小多了。

6）成熟的工作流，branch 不方便没问题，一般 release/trunk/develop 三级分支就够了，平时大家都在 develop 分支上开发，每周一冻结版本，merge 回 trunk 开始测试 trunk，稳定下来以后再从 trunk 合并到 release 对外发布，hotfix 直接在 trunk 上做，测试通过又分别合并回 release 和 develop，非常清晰的工作流，有什么大功能的话再分出一个来。

7）负担轻，用 git 最大的负担就是天天 merge/rebase，这负担比 svn 重很多。

8）单调递增的纯数字版本号：13001, 13002, 13003 看着比一大堆 hash 标记直观，可以大模大样的写到测试邮件里，可以高效率口头交流，别人说个数字你就基本有概念，大概何时提交的？谁前谁后？

。。

说公有云 svn 少的，github 本身就可以用 svn 来操作，直接 checkout github url 即可，提交的时候用 github access-token 当密码，就是 ghp_ 开头那个很长的字符串 ，就能提交了。

代理的话 svn 一样可以配置，码云和 coding.net 等也都同时支持 git/svn。

。。

更没必要把用个工具上升到宗教程度去信仰，多角度看问题，别人的说法自己也想一想，比如曾经流传的：

说法1：git 可以当作 svn 用，svn 却不能当作 git 用，这说的是 git 可以完全包含 svn，根据上面几条，细究起来显然不是这样的。

说法2：git 是分布式的，中心挂了可以恢复；没毛病，但你又不是 linux kernel 需要全球协同，你一个公司项目，团队里所有人都坐在一起办公，即便有人在家工作也有强有力的组织约束，你是联不通内网非要用分布式还是说公司系统不可靠到备份需要依靠每个程序员的 working copy ？

说法3：git 可以方便做分支，没毛病，确实是 git 的长处；但它不经意间植入了一个潜台词 ，即“你需要频繁做分支”，真的是这样的么？还是看各个团队自己的工作流才对吧？上面三级分支的工作流在若干团队里成熟稳定的跑了多少年了，不需要像 git 一样每人每天都要处理合并问题。分支满天飞的代价就是下班前想推代码手慢被同事先 push 了，自己就只有晚半小时回家了。

这里并不是呼吁大家用 svn 代替 git，不用那么二极管思维，而是没必要把 git 当作 zz 正确，适当的时候需要用 svn 也开开心心的用就是。