svn update 的坑


svn update 没有效果 ; svn update 无法覆盖本地文件

一般情况下公司里的所有人都会叫你在别人修改完成时,使用update来将版本库的代码同步进来。这没有错。但是用过github的人都不是很理解这个命令,因为在git中有commit + pushcheckout + 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 是这样计算的

  1. 当你的文件处于最新版本,且文件内的修改 新于 版本时间,那么update 将无效(没有任何效果)
  2. 当你的文件处于非最新版本,且有修改内容 与 版本库不冲突(或者svn可以解决的冲突)update能够正常使用,而且保留你的修改内容,并使得版本库的修改也更新进来。回到 1 状态
  3. 当你的文件处于非最新版本,且冲突无法解决,svn 返回 C 也就是冲突状态,那么你就默默解决冲突吧

可见事实上,svn update 的其实是为了保护你本地修改而做的先一步merge,这个是用git的同学无法简单理解的(就像我一样),因为其实svn事实上没有分支的概念,分支也只是另开一个文件夹,可以理解为辅主分支,所有人都是在辅主分支上干活,所以每次update的是别人的代码,自己的工作区一定不能被覆盖或者抛弃。
但git 的思路其实是不一样的,每个人都有自己的分支(真分支)做完以后merge到主干(无论是辅主干还是真主干)所以每次我们需要做的仅仅是把自己的分支内容 checkout 到自己的工作区,没有svn 那种问题。并且我会在本地做一些log 或者简单的测试代码,用完即删的那种,测完了,就可以checkout,so happy。保证自己的工作区或者版本库是干净的。但是svn 用久了就会发现本地工作区很乱,有时候commit的时候都会把一些奇怪的测试代码(提交前你没仔细diff的话)一并交上去。要扯到 ignore 和 ci 方式上去了,打住。

结束语

那么如果真的你需要覆盖本地文件的话怎么办呢?一种是删除再 update,另一种是revert命令。可以将本地文件和版本库文件真正同步成一模一样。

推荐阅读更多精彩内容

  • 命令的使用 1、检出 svn cohttp://路径(目录或文件的全路径)[本地目录全路径] --username...
    小李龍彪阅读 2,917评论 0 9
  • iOS 开发 SVN 版本控制器 更多技术交流请加群 iOS技术联盟 27512466 SVN是Subversio...
    Sunny_Fight阅读 6,952评论 7 62
  • SVN SVN使用 基本操作svn checkout:把项目源码下载到本地,只需要做一次svn update:将本...
    彼岸的黑色曼陀罗阅读 1,061评论 0 4
  • &开发过程中离不开源代码的管理, 目地:为了解决在软件开发过程中,由源代码引发的各种蛋疼、繁琐的问题。 目前开发使...
    早起的虫儿子被鸟吃阅读 1,819评论 0 15
  • 曾以为, 早已忘却, 那似水的年华, 以及彩虹般的梦, 如晶莹的雪般, 随着春风, 消散的无影无踪。 不曾想, 你...
    十八贝勒阅读 59评论 1 1