svn管理流程实践

整 理:吴万利
时 间:2015-01-08
说 明:svn管理流程实践

svn目录结构

trunk 主干:存储最新稳定的版本
tags 标记:主要保存比较完整的版本标记,类似里程碑
branches 分支:用于分工操作,以开发分支、用户名、日期为目录存储

svn工作模式

常用的两种工作模式

基础结构准备

选定trunk为主要开发文件夹
tag为发布版本的地方(可能也有紧急的bug修复,之后要将代码合并回主干)
branch为分支目录(bug修复、模块独立开发等)

现有的文件结构

trunk/ 主要开发的目录

*.php

tag/ 版本发布目录(发布tag一定要标记信息!)

release_1.0 已经发布的一个版本(1版本号,0修订号)

branch/ bug修复,独立模块开发等

问题应对流程

  1. 日常的开发怎么办?
    答:日常可以在trunk里面进行开发,周期不长开发测试完成可以打包出来进行测试。

    • 开发完成之后由管理人员操作打包得到
      http://svnxxx.xxx.com/svn/vshop2_trade_module/tag/release_2.0
    • 在测试机上测试稳定之后就可以准备上线
      上线:可以在对应项目目录下面执行svn switch命令(我的方案)
  2. 线上的项目出现问题怎么办?
    • 紧急而且简单
      1. 直接在release里面修改(其实不推荐,而且测试机的配置,同样用switch命令?),然后测试提交,在线上更新。
      2. 通知trunk、branch里面的dev进行merge(merge前提交所有改动!)
    • 不紧急而且较复杂
      1. 在branch里面copy一个release_1.0版本为dev_1.0_bugfix进行修改
      2. 测试通过之后发布为tags/patch_1.1 通知trunk等进行合并操作
  3. 开发新的独立模块怎么办?
    答:可以考虑在branch下复制一个当前稳定版本的dev_2.0_yilucaifu出来进行修改,测试完成之后可以独立上线,但是不要忘记合并。

情景模拟

0. 情景准备

svn仓库结构:

branches
tags

release_1.0

trunk

服务器上代码结构:

正式版

tvshop2_online(svn:tags/release_1.0)

测试机

tvshop2_online_dev(svn:trunk)

1. 上线的东西出问题,需要调试

  1. 对于tag版本出一个bugfix分支

    svn cp
    http://svnxxx.xxxx.com/svn/tvshop2/tags/release_1.0http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix
    -m '1.0bug修复'

  2. 测试版切换到分支

    tvshop2_online_dev:
    svn switch http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix

  3. 测试版debug,测试提交

    tvshop2_online_dev:
    svn ci -m 'debug message'

  4. 发布一个新的版本

    svn cp
    http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfixhttp://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1
    -m 'bug修复'

  5. 改动上线

    tvshop2_online:
    svn switch http://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1

  6. 清理无用分支dev_1.0_bugfix

    svn del http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix -m '已经上线'

  7. 合并改动到主分支
    tip:一般线上的紧急调试都不会太大,所以合并一般问题都不会很多

    1. 切换测试机为主分支
      tvshop2_online_dev:
      svn switch http://svnxxx.xxxx.com/svn/tvshop2/trunk
    2. 合并改动到主分支(推荐在windows下用工具辅助做)
      svn merge http://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1/ ./
    3. 下次提交将改动一起提交即可

2. 新的模块的开发

  1. 开发之前先大致确定一下可能的改动,是否跟原来的开发改动了同一块地方。
  2. 对于需要共同修改的地方在合并的时候必须小心处理,可以跟原来的开发一起查看改动是否合理。

3. 优点:

  1. 线上代码稳定,可靠性高(除非有人故意删除release)
  2. 回退方便,能够很清楚的知道上个版本是哪个

4. 缺点:

  1. 操作复杂,繁琐,比较容易搞混当前的版本是哪个
  2. merge回当前开发分支的时候可能会引起冲突(无法避免)
  3. 线上如果有人修改可能会引起树冲突,所以切换之前需要提交所有改动

5. 原则总结:

  1. 在执行switch的之前一定要提交所有的改动。
  2. 每次发布新版本之后其他分支需要从trunk上merge来获取最新的版本(冲突的话需要协商解决)。

仓库迁移记录

  1. 准备好即将使用的svn仓库
  2. 在线上先co出两个文件夹备用(svnshop2+svnshop2_dev)
  3. 将线上的代码export一份作为一个基础版本,并发布一个tag(release_1.0)
  4. 将本地开发的所有改动提交到之前的仓库
  5. 将之前的仓库文件导入到现在的svn里面的trunk中
  6. 在线上测试机co trunk,测试各项功能是否ok(测试一起购、一路财富改动都没有问题)
  7. 以后上线:trunk发布新的tag,线上执行switch操作(确保线上svn里面的文件没有M状态!)

可能的问题

  1. crontab怎么办?(直接在服务器上做的alias,没有影响原结构)
  2. 静态文件上线?(只能针对静态文件单独做合并、上线)
  3. 以后数据库的改动怎么同步?

 

One thought on “svn管理流程实践”

  1. 1、 “每次发布新版本之后其他分支需要从trunk上merge来获取最新的版本(冲突的话需要协商解决)。”
    还有一种解决方法:svn里删除分支重新创建,代码里svn up一遍即可。
    2、switch可以简单理解为svn up,只不过源变成了另一个仓库;所以M状态的文件会被更新(仍然保持M状态),也可能产生冲突(两边同时修改,状态C)。
    3、个人建议是,所有耗时的操作(修改release上的BUG、开发功能)都在分支里进行。
    4、一个活动的资源文件可以单独放一个文件夹,方便活动结束后清理,使仓库的体积维持在较小的范围内。

发表评论