不同文件修改的处理
SVN 的自动合并这些修改
• 不同人修改不同文件，不会有任何提示，对于工作以文件划分职责的人表示很 OK，也是策划配表文件要求写一个“合并”工具的源头。
• 对于一个项目中，不同文件的内容有互相关联的功能来说，可能导致第三方错误。导致“在我机器上很好啊？”问题频繁发生。
GIT/Perforce 的需要开发者先更新再提交
• 不管改了什么，都提示开发者处理，当“网盘”使用的人表示很烦
• 因为都经过开发者合并，所以可以自动做一些单元测试等验证工作，减少问题
对于分支的使用方法
SVN 的分支是目录
• 优势：分支就是目录，非常直观，不需理解，当“网盘”用即可
• 问题：
￮同时拥有多个分支，需要下载多个目录很占硬盘
￮如果使用一个目录，切分支时要联网，可能很慢
￮习惯不切分支，而是在多个分支目录上直接改文件的用户，天长日久之后，已经合并不回去了
GIT/Perforce 的分支不是目录
• GIT/Perforce 的问题：分支看不见，不直观；要用专门的软件如 SourceTree 才能看见
• GIT/Perforce 的优势：切换分支快
权限管理
SVN/Perforce 的权限
权限可以细分到项目里的目录
GIT 的权限
这个特性 GIT 完败，一个项目只能使用同一套权限，如果有大量的项目互相依赖，要拉代码需要申请几十个权限（因此诞生了字节内部的“一键批量申请权限”的工具）。这也是 Google 嫌弃 GIT 的主要原因。
其他差别
• 非 git 无法提供无网络的快照、回滚能力，对于离线开发，譬如在飞机上写代码不友好（听起来并没什么用?）
• .svn/ 目录到处都是，.git/ 只有一个。但是，太多 .svn/ 在代码搜索等操作上，造成很多麻烦，一搜一大堆同名函数在 SVN 内部文件里。
总结
• 对于工作互相隔离、非文本类（源代码）文件开发的用户，SVN 非常直观，基本当作网盘使用即可（svn update 等于下载文件；svn commit 等于上传文件；开分支就是拷贝个目录，合并是不存在的），无学习成本。但是对于共同开发源码的程序员来说，这种模拟成目录的设计，会导致很多误用，从而产生问题。
• 对于代码开发人员，自动合并是一个核心问题，使用 SVN 具有其固有缺陷。
