整 理：吴万利
时 间：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. 以后数据库的改动怎么同步？