svn经典工作流程实例模拟

最新推荐文章于 2020-06-12 04:37:08 发布

子谋

最新推荐文章于 2020-06-12 04:37:08 发布

阅读量963

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/MESH4444/article/details/17334619

本文通过模拟项目开发过程，详细介绍了SVN的基本工作流程，包括项目启动、权限设置、代码提交、冲突解决、版本控制等环节，帮助读者理解和掌握SVN在团队协作中的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文以模拟项目开发过程的手段，详细描述svn的工作流程，本文旨在尽可能的覆盖一些常用情况，不可能模拟项目的方方面面。只要通过阅读一次流程，加之google和baidu的帮助，能够应付80%的项目开发足以……

基本流程以及遇到的困难的如下：

项目启动，研发三人：张三，李四，王五（为了减少不必要的复杂度，不设测试人员等），三个研发人员分别负责三个部分的研发：控制、存储和展示。另设项目经理，安排三名研发的工作，并负责svn标签以及里程碑的管理

新建一个svn项目管理目录
- svn管理员：svnadmin create project_name
- svn管理员：修改配置项，设定三人的权限，修改svn端口等
- svn管理员：svn mkdir branches tags trunk（创建三个标准目录）
checkout初始项目，并开始工作：
- 经理：创建文件
  - svn co svn://svn_address
  - cd trunk
  - touch control.c store.c display.c
  - svn add *
  - svn ci -m 'starting working'
- 张三：开始编码，并提交更新
  - svn co svn://svn_address
  - vi trunk/control.c
  - svn st
  - svn ci -F msg.file
- 李四：开始编码，并提交更新
  - svn co svn://svn_address
  - vi trunk/store.c
  - svn st
  - svn ci -F msg.file
- 王五：开始编码，并提交更新
  - svn co svn://svn_address
  - vi trunk/display.c
  - svn st
  - svn ci -F msg.file
三个人每天如此，编写自己的模块，定期提交一份可编译版本，由于编写的都是独立的文件，所以一直都相安无事
好景不长，李四的模块相对简单，所以李四很快就把所有事情做完了，项目经理要求李四与张三双人开发，加快工作进度
- 李四：更新全部代码，方便与张三一起协作
  - svn up
  - vi trunk/control.c
- 张三：依旧按照自己的节奏开发
  - vi trunk/control.c
  - svn st
  - svn ci -F msg.file
- 李四：倒霉的发现自己update的代码不是最新的，于是找张三商量怎么解决
  - svn st
  - svn up（发现冲突）
  - vi trunk/control.c（修改冲突）
  - svn resolved control.c（解决冲突）
  - svn st
  - svn ci -F msg.file
王五自己干的特来劲，结果得以忘型，代码写错了，幸好还没提交。好在离上次提交没改多少行，干脆还原重写吧
- 王五：
  - svn diff（查看最新修改的部分有哪些）
  - svn revert display.c（撤销全部最新修改）
项目过了一大半，经理想了解一下进度，看看大家代码提交的状况
- 经理：
  - svn log(简单看一下）
  - svn log -v （详细看一下，发现r15解决了一个严重问题）
  - diff -r 14:15（看看是怎么解决的）
项目进入联调阶段
李四检查代码的时候发现了一个棘手的bug，为了方便fix bug，李四决定锁定代码，以免张三提交新代码干扰自己修改bug
- 李四：
  - svn lock control.c -m 'fuck zhangsan stop'（锁定代码）
  - vi trunk/control.c
- 张三：
  - svn ci -F log.file（提交被驳回，张三只好等李四解锁）
- 李四：
  - svn ci -F msg.file（提交自动解锁）
项目完成，版本1.0发布
- 经理：创建里程碑v1.0
  - svn cp trunk tags/v1.0（实际上就是目录的复制）
  - svn ci -m 'create v1.0'
1.0版本完成，项目继续升级
- 三名开发人员，继续在trunk中进行开发工作，其过程与上出过程如出一辙
1.0版本发现一个隐含的bug，在branches分支中建立解决bug的分支，好在bug只影响到了v1.0，当前开发会重写bug所在区域，所以不用将此bug合并到当前开发
- 经理：
  - svn cp tags/v1.0/ branches/v1.0_bug1
  - svn ci -m 'handle bug1 of v1.0'
- 三名开发者：处理branches中的的bug分支，最终bug得到修复
- 经理：修复bug，发布1.0.1版本
  - svn mv branches/v1.0_bug1/ tags/v1.0.1
  - svn ci -m 'bug1 fixed'
1.0版本中又发现一个bug，并且当前开发并未修改到bug所在区域，所以我们不仅要修改v1.0的bug，同时还要将此bug的修复合并到当前版本中
- 经理：
  - svn cp tags/v1.0.1/ branches/v1.0_bug2
  - svn ci -m 'handle bug2 of v1.0'
- 三名开发者：处理branches中的的bug分支，最终bug得到修复
- 经理：
  - svn cp branches/v1.0_bug2/ tags/v1.0.2
  - svn ci -m 'bug2 fixed'
  - cd branches/v1.0_bug2/
  - svn log -q --stop-on-copy(此log告诉我们当前目录从被复制到现在所有的记录(-q表示短记录)）
  - svn merge -r 27:HEAD ../branches/v1.0_bug2/（将分支目录下，从r27到现在的所有修改合并到当前目录）
  - svn ci -m 'merge fix of bug2 in trunk‘
由于v2.0的开发既要有新功能，又随时可能合并v1.0中的bug，难免出错，终于在某一天发现代码不可用了，需要回滚
- 经理：
  - cd tags
  - svn log -q(看看v1.0是什么时候发布的，代码可以从v1.0以后进行定位）
  - svn log -r 23:HEAD control.c(查看这个写乱的文件，都发生过哪些修改)
  - svn diff -r 28:HEAD control.c(发现control.c文件在v1.0版本后，首次更新是r28，所以我们比较r28到当前版本的区别）
  - 由于svn无法一次性查看每一次的修改记录，而一个一个的查又太麻烦，所以经理放弃了修改的想法，决定回滚
  - svn up -r 28 control.c(将control.c更新到r28，也就是v1.0时候的版本，发现这个版本不可用，如果回滚到这个版本，所有2.0的开发都白做了）
  - svn up -r 30 control.c（将control.c更新到r30，发现这个版本基本可以，决定就回滚到这个版本）
  - svn up(更新到最新版本，准备合并）
  - svn merge -r HEAD:30 control.c（撤销从当前版本到r30之间的所有操作，代码回归到r30）
  - svn ci -m 'control.c back to r30'（确认回滚）