svn update 没有效果 ； svn update 无法覆盖本地文件
一般情况下公司里的所有人都会叫你在别人修改完成时，使用update来将版本库的代码同步进来。这没有错。但是用过github的人都不是很理解这个命令，因为在git中有commit + push和checkout + pull来分别提交和下拉版本库，而自己的文档一般都是在分支下完成。
！此时如果初学者，例如我，单纯地把update理解为checkout的话（实际上用法很类似！！），你将付出一定的代价。解释在下文，伸手党直接跳转 结论。
假设在电脑1提交一个文件如下：
test
abc
svn commit -m 'first commit'
#假设此时版本为 1
当你在另外一台电脑2上，co 进来时文件内容应当是一样的
此时电脑1上做修改：
test
abc
computer1 add
并且同时在电脑2上做修改：
test
computer2 add
abc
ok, 万事妥当，当电脑1提交commit -m 'second commit #假设此时版本为 2'
此时，电脑2上 进行update会出现一个 G 表示版本库文件与本地文件有冲突，但是svn已经帮你解决
电脑2的文件是这个样子的：
test
computer2 add
abc
computer1 add
也就是说，update并不会覆盖你本地的工作目录，此时电脑上的结果是svn 还有 diff 但是版本已经成为 2 ，这就是很多人update了但没有效果的实际例子。
那么经过查看文档和多方验证得出以下结论。
<a id="jump" name="jump">结论</a>
svn update 是这样计算的
- 当你的文件处于最新版本，且文件内的修改 新于 版本时间，那么
update将无效（没有任何效果） - 当你的文件处于非最新版本，且有修改内容 与 版本库不冲突（或者
svn可以解决的冲突）update能够正常使用，而且保留你的修改内容，并使得版本库的修改也更新进来。回到 1 状态 - 当你的文件处于非最新版本，且冲突无法解决，
svn返回 C 也就是冲突状态，那么你就默默解决冲突吧
可见事实上，svn update 的其实是为了保护你本地修改而做的先一步merge，这个是用git的同学无法简单理解的（就像我一样），因为其实svn事实上没有分支的概念，分支也只是另开一个文件夹，可以理解为辅主分支，所有人都是在辅主分支上干活，所以每次update的是别人的代码，自己的工作区一定不能被覆盖或者抛弃。
但git 的思路其实是不一样的，每个人都有自己的分支（真分支）做完以后merge到主干（无论是辅主干还是真主干）所以每次我们需要做的仅仅是把自己的分支内容 checkout 到自己的工作区，没有svn 那种问题。并且我会在本地做一些log 或者简单的测试代码，用完即删的那种，测完了，就可以checkout，so happy。保证自己的工作区或者版本库是干净的。但是svn 用久了就会发现本地工作区很乱，有时候commit的时候都会把一些奇怪的测试代码（提交前你没仔细diff的话）一并交上去。要扯到 ignore 和 ci 方式上去了，打住。
结束语
那么如果真的你需要覆盖本地文件的话怎么办呢？一种是删除再 update，另一种是revert命令。可以将本地文件和版本库文件真正同步成一模一样。