碰到要使用svn的场景,在这里总结一下,虽然git横着走,偶尔也要关怀一下老前辈
一些通用场景
查看日志
svn log代码锁定或很多诡异情况
svn cleanup编辑特定属性
定制忽略规则
svn propedit (pedit, pe) svn:ignore .依赖其他SVN路径
svn propedit (pedit, pe) svn:externals .svn客户端更新
svn upgrade
一个分支上的工作流程
入职
加入一个现有项目
你新加入某个团队,马上要参与到一个项目得开发,假设项目名为'abc',那么首先要做的是获取项目代码
svn checkout (co) https://your.svn/svn/abc/trunk abc确认工作目录中SVN得信息
cd ~/projects/abc
svn info确认没有问题,就可以开始熟悉代码,展开具体的工作了
发起一个新项目
当然,也有可能是由你开始发起一个项目,那么就需要初始化项目工程放到SVN版本仓库中
svn import abc https://your.svn/svn确认初始化成功
svn list (ls) https://your.svn/svn/abc/trunk
苦逼的码农上班
当你已经融入一个项目后,就会进入一个工作周期,周期可能是这样的
- 更新
- 修改
- 检查
- 取消修改
- 解决冲突
- 提交
更新
来上班,打完卡,准备开始上班,第一件事就是更新你的工作目录
cd ~/projects/abc
svn update (up)这样保证你的工作副本是最新的,并以此为基础开始工作
修改
打开编辑器修改属于常规用法,这里pass
新增模块
svn add new_module.py
移除模块
svn delete (del,remove,rm) old_modele.py
重命名模块
svn move (mv) module1.py module2.py
新增目录
svn mkdir directory
复制模块
svn copy (cp) dir/module.py /dir2/module.py
终于一个任务完成了
忙碌的一天过去了,又或者终于完成一个任务了,为了不做白工,需要将工作成果更新到版本仓库
- 检查一下修改状态
- 代码审查(code review)一下
要先检查一下修改状态
svn status (stat,st)执行上述命令会看到一些状态信息,可以看到修改了哪些文件,接下去一般会进行代码的审查工作(虽然实际中很多人把这步跳过去,但我个人认为不应该跳)
代码审查
代码审查的主要目的是要自己写的代码能通过单元测试,如果没有问题就要进行"提交"代码了,然后结束一个工作周期,当然,一般情况下没有那么顺利,总会出现一些特殊情况
查看代码做了哪些修改
svn diff (di)发现有些改动不满意,取消修改
svn revert abc.py查看代码是谁写的
svn blame (praise, annotate, ann)提交代码的流程
提交代码需要经过如下过程
- 再一次更新自己的工作副本
- 将别人提交的工作代码进行合并(解决冲突)
- 提交代码
再一次更新自己的工作副本
这一步即使不手动执行,也会出现这样一种情况,就是直接提交代码,发现没有提交成功,一看,原来别人也提交了代码,并且好死不死正好和你的代码属于同一个位置,这样也会产生冲突,所以建议提交代码前手动更新一次工作副本
svn update (up)更新完工作副本,很多时候会产生代码冲突,既然冲突了,就是要解决冲突。由于各个工作的实际环境不一样，究竟是自己解决冲突还是别人处理，亦或者有其他额外处理，这都不一定，这边假设后提交代码的处理冲突（也就是你自己处理冲突），
处理冲突
- 人工确认并进行代码合并
- 处理完毕后执行的命令
svn resolve abc.py --accept working - 也有一个命令叫做
svn resolved abc.py //这个命令按官方的说法是被上一个命令取代了,不推荐使用了
冲突解决了,最后提交
svn commit (ci)
分支之间的操作
创建新分支
svn copy (cp) https://your.svn/svn/abc/trunk https://your.svn/svn/abc/branches/feature1切换到新分支
确认当前在哪个分支
svn info确认工作目录是干净的
svn status (st)切换到刚刚创建的新分支
svn switch (sw) https://your.svn/svn/abc/branches/feature1在新分支中工作
就是上述的流程,一般情况下我们在分支上进行工作,不管是新特性分支还是debug分支
当我们开发完一个新功能,或者排除一个bug之后,相关功能代码,测试代码,文档等都提交完毕,单元测试通过,代码审查没问题,审核通过,并在该分支的持续集成完整build同故宫,这个时候,就可以将开发分支合并到主分支(trunk)了
合并到主分支
确认分支工作目录干净
svn status (st)切换工作目录会trunk(其实就是切换分支)
svn switch (sw) https://your.svn/svn/abc/trunk切换完分支要确认当前在哪个分支(是否切换成功)
svn info进行合并工作
svn merge -r9527:9549 https://your.svn/svn/abc/branches/feature1- 合并分支的时候,一般会指定合并版本范围,一般都是分支建立时候的版本号到分支工作完毕时候最后一次提交的版本号,就是上述命令中-r后面的参数
- 合并过程中很大情况下会出现代码冲突,解决就是了
确认本地代码变更,代码审查一下,进行单元测试
svn status(st)
svn diff(di)确认合并完的代码没有问题,就正式提交到trunk
svn commit (ci)合并完成之后,开发分支就没有用了,在适当时机删除(主要是公司制度)
svn delete (del, remove, rm) https://your.svn/svn/abc/branches/feature1
开发周期结束,发布新版本
一般来说,我们有一个发布分支复制了trunk,当然我也常碰到以trunk作为发布分支的
svn copy (cp) https://your.svn/svn/abc/trunk https://your.svn/branches/2.1.x
复制最新的发布分支为标签
svn copy (cp) https://your.svn/branches/2.1.x https://your.svn/svn/abc/tags/2.1.0
正式发布(这个一般是自动化工具完成的)
发布总的来说是比较复杂的,比如有:快速发布、快速回滚（包括数据回滚）、灰度发布等等
情况一:完整包
导出代码,执行打包命令(有些动态语言是不需要打包的)
svn export https://your.svn/svn/abc/tags/2.1.0 abc
情况二:补丁升级包
这其实相对复杂,如果代码体量不是非常大,基本上使用情况一就行,因为需要综合运用下列命令,制作补丁安装升级包
svn status (st)
svn diff (di)
svn patch
情况三:线上更新(不推荐,看看就好)
特别注意不能暴露“.svn”(特别是旧版本的SVN，每个目录下都会有“.svn”)
svn update (up)
svn switch (sw) https://your.svn/svn/abc/tags/2.1.0
事实上,很多场景都是由自动化工具(即使是手动写脚本)可以代替手工操作,基本上都是一键发布
好习惯要保持
- 保持工作目录干净,即保证工作副本中的代码是一次完成一件事,如上流程可以看出来,如果目录不干净会导致很多冲突
- svn日志信息要使别人阅读的时候能知道本次提交做了什么
- svn提交之前要先更新,如果是用小乌龟图形界面没有这个问题,但是如果不先更新,各种冲突是很难受的
- 提交之前进行代码审阅是一种更加严谨的方式,如果自己发现不了问题,可以试试小黄鸭调试法
- 提交之前跑一下单元测试可以使代码更加健壮
- 代码有变更要及时提交,一般会在自己的开发分支中进行
结束
这里涉及的场景很有限,官方文档还是要看的
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。