zoukankan      html  css  js  c++  java
  • 关于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的时候很麻烦,容易死人。

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

  • 相关阅读:
    LeetCode Path Sum II
    LeetCode Longest Palindromic Substring
    LeetCode Populating Next Right Pointers in Each Node II
    LeetCode Best Time to Buy and Sell Stock III
    LeetCode Binary Tree Maximum Path Sum
    LeetCode Find Peak Element
    LeetCode Maximum Product Subarray
    LeetCode Intersection of Two Linked Lists
    一天一个设计模式(1)——工厂模式
    PHP迭代器 Iterator
  • 原文地址:https://www.cnblogs.com/newstar/p/svn.html
Copyright © 2011-2022 走看看