碰到要使用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/abcsvn info确认没有问题,就可以开始熟悉代码,展开具体的工作了发起一个新项目当然,也有可能是由你开始发起一个项目,那么就需要初始化项目工程放到SVN版本仓库中svn import abc https://your.svn/svn确认初始化成功svn list (ls) https://your.svn/svn/abc/trunk苦逼的码农上班当你已经融入一个项目后,就会进入一个工作周期,周期可能是这样的更新修改检查取消修改解决冲突提交更新来上班,打完卡,准备开始上班,第一件事就是更新你的工作目录cd ~/projects/abcsvn 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)确认合并完的代码没有问题,就正式提交到trunksvn 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提交之前要先更新,如果是用小乌龟图形界面没有这个问题,但是如果不先更新,各种冲突是很难受的提交之前进行代码审阅是一种更加严谨的方式,如果自己发现不了问题,可以试试小黄鸭调试法提交之前跑一下单元测试可以使代码更加健壮代码有变更要及时提交,一般会在自己的开发分支中进行结束这里涉及的场景很有限,官方文档还是要看的