关于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的时候很麻烦,容易死人。

其实,这里并没有一定之规,更多的时候是两种 模式结合使用。

转自:http://www.cnblogs.com/newstar/archive/2011/01/04/svn.html

时间: 2024-10-11 15:12:19

关于SVN 目录结构的相关文章

源代码管理工具(下)-SVN目录结构

正规项目的SVN目录结构一般有3个文件夹:trunk:主干,当前开发项目的主目录branches:分支目录,添加非主线功能时使用,开发测试之后,可以合并到主干项目中tags:标记目录,通常作为重大版本的备份 在svn服务器上再次创建一个仓库,这个仓库死真正的仓库,包含了trunk.branches.tags三个文件夹,模拟开发.修复bug.合并版本的流程. 1.创建仓库 2.命名仓库 3.初始化仓库: 4.访问设置: 5.仓库创建成功,预览URL: 6.查看创建的三个文件夹: 7.接下来,根据项

SVN目录结构

整理了一下svn目录结构,如下: 项目名称 ----branches    软件产品的迭代开发版本 ----tags        软件产品经过完整测试的历史稳定版本,已部署在客户机器上使用的 ----trunk       软件产品当前的主干开发版本 --------libraries  软件开发依赖的库(dll/jar).组件等 --------target    软件编译生成的目标目录 ----docs        软件相关文档 --------00管理 ------------00项目

保持SVN仓库结构只checkout部分子目录

有时整个 svn 目录太过于庞大,不想整个 checkout 下来,但又想维持整个目录结构以方便后续使用,那么可以使用 subversion 1.5 之后的 –depth 参数来只 checkout 需要的子目录. # 先checkout空目录svn co --depth empty svnLocation localDir # 对需要的子目录递归checkoutsvn update --set-depth infinity localDir/datasvn update --set-depth

Android SVN开发实战之目录结构介绍

svn有一个很标准的目录结构,是这样的.比如项目是proj,svn地址为svn://proj/,那么标准的svn布局是 svn://proj/ | +-trunk +-branches +-tags 这 是一个标准的布局,trunk为主开发目录,branches为分支开发目录,tags为tag存档目录(不允许修改).但是具体这几个目录应该如何使 用,svn并没有明确的规范,更多的还是用户自己的习惯. 对于这几个开发目录,一般的使用方法有两种.我更多的是从软件产品的角度出发 (比如freebsd)

02 svn 文件提交与目录结构

一:文件操作给svn服务器提交程序文件: ① 在被提交文件的身上点击右键------> tortoiseSVN----->add ② 在被提交文件身上点击右键------> commit ③ 如果不 成功,开启匿名用户访问权限(d:/svnserver/shop/conf/svnserve.conf) ④ 继续commit操作 备注[修改匿名权限]:svnserve.conf => 添加: anon-access = write 二:目录结构 文件在仓库的什么地方存放: ① 日志在

SVN仓库目录结构

SVN仓库目录结构Repository: trunktagsbranches trunk(主干|主线) branchs(分支) tags(标记) truck(主干|主线|主分支):是用来做主方向开发的,新功能的开发应放在主线中,当模块开发完成后,需要修改,就用branch.branch(分支):分支开发和主线开发是可以同时进行的,也就是并行开发,分支通常用于修复bug时使用 tag(标记):用于标记某个可用的版本,可以标记已经上线发布的版本,也可以标记正在测试的版本,通常是只读的 SVN具体操作

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

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

SVN标准目录结构

Trunk 这是SVN目录的主分支,表示日常开发中的项目,任何时候Trunk里包含的都是最新的开发代码. 这里的代码将会工作到你的下一个主要发布版本. Trunk应该只被用来开发将会成为你的下一个重要版本的代码. Branches 分支 Experimental branches 有时你想将某个新技术引进项目.这很好,但是你当然不想赌上你的整个项目. Bug fix branches 分支也可以用于处理trunk或release branches里发现的严重的Bug. Tags 一般情况下,ta

Maven学习-目录结构

Maven学习-入门 1. 什么是Maven 2. 如何用Maven来构建项目 3. Maven项目的目录结构 Maven约定了一套规则来创建和构建项目.得益于Maven的一些约定,我们只要学习相对很少的命令就可以创建和管理我们的项目.在项目的目录结构上,Maven有一套约定的通用的目录结构. 使用一套通用的目录结构的好处是,可以减少开发人员熟悉不同Maven项目时的认知负担.在使用相同的目录结构的情况下,开发人员可以很快的熟悉一个项目. 1.Maven通用的目录结构介绍 通用目录结构 Mave