zoukankan      html  css  js  c++  java
  • Android SVN开发实战的文件夹结构呈现

    svn有一个非常标准的文件夹结构,这是。

    例如,该项目是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.0开发完成,代码 冻结
    基于已经冻结的trunk,为release1.0打tag
    此时的文件夹结构为

    svn://proj/
    +trunk/ (freeze)
    +branches/
    +tags/
        +tag_release_1.0 (copy from trunk)

    2.0 開始开发。trunk此时为2.0的开发版
    发现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)

    在1.0 bugfix branch进行1.0 bugfix开发,在trunk进行2.0开发
    在1.0 bugfix 完毕之后,基于dev_1.0_bugfix的branch做release等
    依据须要选择性的把 dev_1.0_bugfix这个分支merge回trunk(什么时候进行这步操作,要依据详细情况)
    这是一种非常标准的开发模 式。非常多的公司都是採用这样的模式进行开发的。trunk永远是开发的主要文件夹。



    另外一种方法

    在每个release的branch中进行 各自的开发。trunk仅仅做公布使用。

    这样的开发模式其中,trunk是不承担详细开发任务的,一个版本号/阶段的开发任务在開始的时候。依据已经 release的版本号做新的开发分支,而且基于这个分支进行开发。还是举上面的样例,这里面的时序关系是。


    1.0开发,做 dev1.0的branch
    此时的文件夹结构
    svn://proj/
    +trunk/ (不担负开发任务 )
    +branches/
        +dev_1.0 (copy from trunk)
    +tags/

    1.0开发完毕,merge dev1.0到trunk
    此时的目 录结构
    svn://proj/
    +trunk/ (merge from branch dev_1.0)
    +branches/
         +dev_1.0 (开发任务结束。freeze)
    +tags/

    依据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)

    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)

    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)
    选择性的进行代码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进行主要开发。集中式):

              长处:管理简单
              缺点:当开发的模块比較多,开发人数/小团队比較多 的时候。非常easy产生冲突而影响对方的开发。由于全部的修改都有可能触碰对方的修改。

    另外一种开发模式(分支进行主要开发,分散式):

              长处:每 自独立的发展,不easy相互作用。
              缺点:管理复杂,merge很麻烦的时间,easy死。


    其实,而不是明显的在这里。许多其它时间两种 模式组合。

  • 相关阅读:
    SharePoint 2010 User Profile Sync Service自动停止
    如何区别多个svchost.exe?
    Log Parser分析IIS log的一个简单例子
    Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
    Windows中右键点击文件夹, 结果找不到共享选项卡, 怎么办?
    介绍SOS中的SaveModule命令
    SharePoint中Draft版本的文档不会收到document added的Alert Email
    和我一起学Windows Workflow Foundation(1)创建和调试一个WF实例
    门户网站
    C#基础—— check、lock、using语句归纳
  • 原文地址:https://www.cnblogs.com/yxwkf/p/4600371.html
Copyright © 2011-2022 走看看