使用svn开发,目录的约定与开发流程

Subversion有一个很标准的目录结构,是这样的。
比如项目是proj,svn地址为svn://proj/,那么标准的svn布局是

svn://proj/
|
+-trunk
+-branches
+-tags

这是一个标准的布局,trunk为主开发目录,branches为分支开发目录,tags为tag存档目录(不允许修改)。但是具体这几个目录应该如何使用,svn并没有明确的规范,更多的还是用户自己的习惯。

对于这几个开发目录,一般的使用方法有两种。我更多的是从软件产品的角度出发(比如freebsd),因为互联网的开发模式是完全不一样的。
第一种方法,使用trunk作为主要的开发目录。
一般的,我们的所有的开发都是基于trunk进行开发,当一个版本/release开发告一段落(开发、测试、文档、制作安装程序、打包等)结束后,代码处于冻结状态(人为规定,可以通过hook来进行管理)。此时应该基于当前冻结的代码库,打tag。当下一个版本/阶段的开发任务开始,继续在trunk进行开发。
此时,如果发现了上一个已发行版本(Released Version)有一些bug,或者一些很急迫的功能要求,而正在开发的版本(Developing Version)无法满足时间要求,这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag,做相应的分支(branch)进行开发。
例如,刚刚发布1.0,正在开发2.0,此时要在1.0的基础上进行bug修正。
按照时间的顺序

  1. 1.0开发完毕,代码冻结
  2. 基于已经冻结的trunk,为release1.0打tag
    此时的目录结构为
    svn://proj/
                 +trunk/  (freeze)
                 +branches/
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  3. 2.0开始开发,trunk此时为2.0的开发版
  4. 发现1.0有bug,需要修改,基于1.0的tag做branch
    此时的目录结构为
    svn://proj/
                 +trunk/  ( dev 2.0 )
                 +branches/
                               +dev_1.0_bugfix (copy from tag/release_1.0)
                 +tags/
                         +release_1.0 (copy from trunk)
  5. 在1.0 bugfix branch进行1.0 bugfix开发,在trunk进行2.0开发
  6. 在1.0 bugfix 完成之后,基于dev_1.0_bugfix的branch做release等
  7. 根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk(什么时候进行这步操作,要根据具体情况)

这是一种很标准的开发模式,很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

第二种方法,在每一个release的branch中进行各自的开发,trunk只做发布使用。
这种开发模式当中,trunk是不承担具体开发任务的,一个版本/阶段的开发任务在开始的时候,根据已经release的版本做新的开发分支,并且基于这个分支进行开发。还是举上面的例子,这里面的时序关系是。

  1. 1.0开发,做dev1.0的branch
    此时的目录结构
    svn://proj/
                 +trunk/  (不担负开发任务 )
                 +branches/
                               +dev_1.0 (copy from trunk)
                 +tags/
  2. 1.0开发完成,merge dev1.0到trunk
    此时的目录结构
    svn://proj/
                 +trunk/  (merge from branch dev_1.0)
                 +branches/
                               +dev_1.0 (开发任务结束,freeze)
                 +tags/
  3. 根据trunk做1.0的tag
    此时的目录结构
    svn://proj/
                 +trunk/  (merge from branch dev_1.0)
                 +branches/
                               +dev_1.0 (开发任务结束,freeze)
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  4. 1.0开发,做dev2.0分支
    此时的目录结构
    svn://proj/
                 +trunk/  
                 +branches/
                               +dev_1.0 (开发任务结束,freeze)
                               +dev_2.0 (进行2.0开发)
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  5. 1.0有bug,直接在dev1.0的分支上修复
    此时的目录结构
    svn://proj/
                 +trunk/  
                 +branches/
                               +dev_1.0 (1.0bugfix)
                               +dev_2.0 (进行2.0开发)
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  6. 选择性的进行代码merge

这其实是一种分散式的开发,当各个部分相对独立一些(功能性的),可以开多个dev的分支进行开发,这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。

这里要注意一下的,第六步进行选择性的merge,是可以当2.0开发结束后一起把dev_1.0(bugfix用)和dev_2.0(新版本开发用)merge回trunk。或者先把dev_1.0 merge到dev_2.0,进行测试等之后再merge回trunk。
这两种方法各有利弊,第一种方法是可以得到一个比较纯的dev_2.0的开发分支,而第二种方法则更加的保险,因为要测试嘛。

以上呢,就是我说的两种开发模式了,具体哪种好,并没有定论。这里大致的说一下各自的优缺点
第一种开发模式(trunk进行主要开发,集中式):
优点:管理简单
缺点:当开发的模块比较多,开发人数/小团队比较多的时候,很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
第二重开发模式(分支进行主要开发,分散式):
优点:各自开发独立,不容易相互影响。
缺点:管理复杂,merge的时候很麻烦,容易死人。

时间: 2024-11-08 12:09:53

使用svn开发,目录的约定与开发流程的相关文章

【转】svn 的开发目录结构和流程

原文: https://blog.csdn.net/iteye_15570/article/details/82548132 ---------------------------------------------------------- Subversion有一个很标准的目录结构,是这样的.比如项目是proj,svn地址为svn://proj/,那么标准的svn布局是 svn://proj/|+-trunk+-branches+-tags这是一个标准的布局,trunk为主开发目录,bran

linux服务器如何设置目录权限,让开发只能在测试目录下开发,不在线上目录上开发

当一台服务器上,既有测试环境,也有生成的环境,开发需要在线上测试,如果开发生产环境的权限,那开发容易误操作 需求如下: (1)生产环境的代码,必须有专用的账号登陆进行管理 (2)开发测试环境的代码,开发能够访问,但访问不了生产环境目录 位了实现这个目的,操作如下 (1)将生产的环境的用户组和拥有者都修改为www //修改用户 chown -R www /product-folder //修改组 chgrp -R www /product-folder (2)设置生产环境的权限为775,也就是只有

python全栈开发目录

python全栈开发目录 linux命令 初识python python基础数据类型 函数编程.set.深浅拷贝 内置函数 文件操作 装饰器 迭代器和生成器 常用模块 初识类和对象 类和对象(进阶) 反射 异常处理 socket.IO多路复用 线程.进程.协程 HTML CSS JavaScript DOM文档操作 jQuery实例 web框架本质 Tornado mysql基础 mysql进阶 ..... 基本算法 递归--二分法查找 冒泡排序 更多 线程池

Python模块:Re模块、附软件开发目录规范

Re模块:(正则表达式) 正则表达式就是字符串的匹配规则 正则表达式在多数编程语言里都有相应的支持,Python里面对应的模块时re 常用的表达式规则:(都需要记住) " . "   #  默认匹配除\n之外的任意一个字符,若指定flag DOTALL,则匹配任意字符,包括换行 " ^ "  #  匹配字符开头,若指定flags MULTILINE,这种也可以匹配上("^a","\nabc\neee",flags=re.MUL

模块(二)之软件开发目录,常用模块

软件开发目录 我们学习编程开始都是将所有的代码全部都放到一个文件里面,后来我们学习函数,模块之后才会说将自己程序的功能具体分一下类,但是因为我们写的程序是需要用户来使用的,对于怎样编程,怎样分类他们都是不了解的,这就需要我们对于软件或者说是程序的开发有一个明确的目录,让不管是自己还是维护人员都可以知道这个程序的大体内容.目录大概结构如下: 对于目录的具体分类大体有以下几类: 1.bin:启动目录,里面只需要有一个启动程序即可,所有文件的启动都由这里开始 2.conf:配置目录,里面是关于程序运行

4 Apr 18 软件开发目录 logging模块的使用 序列化(Json, Pickle) os模块

4 Apr 18 上节课复习:函数在一个程序内被使用,模块可以被几个程序共享使用 一.软件开发目录 confàsettings.py core(主要逻辑)àsrc.py dbàdb.txt lib(库)àcommon.py bin(入口,启动)àstart.py logàaccess.log readme(说明书)   二.logging模块的使用 日志分为五个级别:debug 10, info 20, warning 30, error 40, critical 50 若日志级别设为10,包括

规范开发目录 及 webpack多环境打包文件配置

规范开发目录 普通项目 开发目录: ├── project-name ├── README.md ├── .gitignore ├── assets ├── ├── js ├── ├── css ├── ├── images ├── ├── fonts├── index.html vue 项目开发目录:├── build├── config├── dist├── src├──├── api├──├── assets├──├──├── js├──├──├── style├──├──├──├── b

关于编程编程规范以及开发目录的规范性

如何规范自己的编程以及软件开发目录(一) python 为什么要做这些? 可想而知,随着你的编码慢慢的变多,内容也会变得越来越多:所以,不用想的,规范化自己的编程以及软件开发目录这十分的重要:那么如何做这些东西了?我们作为初学者,目的就是为了遵循代码规范,这是最基本的,而且以后工作了,每个团队的规范还不一样,尽可能的与自己的团队保持一致,目前初学者按照官方要求即可.只要在以后多观察代码风格,多看几次就可以学会了. python中如何规范自己的编程? 关于注释 注释不止为了自己看清楚自己的代码,而

python18 时间模块 系统模块(os,os.path) 项目开发目录规范

复习 '''1.跨文件夹导包 - 不用考虑包的情况下直接导入文件夹(包)下的具体模块 2.__name__: py自执行 '__main__' | py被导入执行 '模块名' 3.包:一系列模块的集合体,通过包内的__init__文件来管理包中所有模块提供给外界的名字 -- 存放所以模块的文件夹名就是包名 4.导包三件事:1)编译__init__文件的pyc2)执行__init__文件形成全局名称空间,作为包的全局名称空间,包能直接使用的名字全部是__init__文件中提供的3)在导包文件中形成