【问题标题】:source control building a branch建立一个分支的源代码控制
【发布时间】:2009-03-23 11:12:14
【问题描述】:

我目前正在为工作评估不同的源代码控制解决方案,并且对分支有一些疑问。

我对如何分支有基本的了解,但我不确定我们的构建机器 (CruiseControl.net) 如何获得分支来构建它。

我们有很多项目,都依赖于其他项目(还有其他项目): 实用工具 > 数据访问 > 业务逻辑 > 通用 GUI >(网站 | 桌面客户端)

我们如何构建存储库(如果这有什么不同,请使用 Vault)以便构建机器能够:

  1. 构建主干
  2. 构建“最新”分支

一个粗略的文件夹结构和/或关于如何从 Cruisecontrol 获取的解释会很棒。

谢谢

编辑:

为了更清楚,我们打算使用主干进行开发,然后为每个版本使用一个分支。

【问题讨论】:

    标签: build-automation cruisecontrol.net nant branch sourcegear-vault


    【解决方案1】:

    如果项目具有不同的发布周期(项目 1 的版本为 1.0,而项目 2 的版本已为 1.1),Mark 提出的解决方案效果很好。如果你所有的项目都是相互依赖的,我会从一个简单的结构开始

    My Big Project
      | 
      +-- trunk
      |     |
      |     +-- utils
      |     |
      |     +-- data
      |     |
      |     +-- business
      |     |
      |     +-- gui (web)
      |     |
      |     +-- gui (swing)
      | 
      +-- branches
      | 
      +-- tags
    

    这样,当你做一个分支/标签时,你确定你已经分支了一切(整个代码)。否则,您在标记时总是有错过一个项目的风险。

    您的构建服务器只需检查主干(包含所有内容)或一个标签/分支(也包含所有内容)并构建/安装版本。

    一旦 utils 包稳定,您可以随时将其“升级”到同级项目并使用 Maven/Ivy 来管理依赖关系。

    【讨论】:

      【解决方案2】:

      “最新分支”是什么意思?分支应该用于主干之外的扩展开发 - 主干应该始终包含最新的生产代码。

      每个项目都应该有trunkbranches 文件夹:

      Project 1
        |-> trunk
        |-> branches
      Project 2
        |-> trunk
        |-> branches
          etc.
      

      然后,您的构建机器可以在本地将任何主干或分支检出到它想要的任何位置(对于您的互连项目,您必须对其进行设置,以便相关目录路径起作用)。在伪脚本中:

      checkout project1/trunk /builds/project1
      build /builds/project1
      

      checkout project1/branches/myBranch /builds/project1
      build /builds/project1
      

      【讨论】:

      • 更新了问题以阐明我们的分支/主干建议用法。 Cruisecontrol(或 nant)如何指定所有名为 */trunk/ 的文件夹?
      • 我不同意'always' 分支可以以多种方式使用ericsink.com/scm/scm_branches.html 建议将它们用于新功能,将主干留作错误修复。使用这种方法,您可能希望构建具有最后一组功能的版本。
      【解决方案3】:

      只是为了澄清在 Vladimir 的方案中如何使用标签和分支。假设您的产品的 1.x 版已退役,2.1 版已发布,而您正在开发 3.0 版:

      trunk <- you're working on version 3.0 here
       project1
       project2
      
      branches
       ReleaseBranch-1.0
       ReleaseBranch-2.0 <-- fixes to version 2.1 (the current production version) get committed here, then merged into the trunk
      
      tags
       Release-1.0 <-- a copy of the source that was used to build version 1.0
       Release-1.1
       Release-1.2
       Release-2.0
       Release-2.1
      

      在您的持续集成/构建服务器中,您将需要 2 个进程:

      • 指向版本控制系统中的主干
      • 在您的版本控制系统上指向 ReleaseBranch-2.0

      Pragmatic Version Control with Subversion 这本书是为 Subversion 设计的,但确实介绍了如何组织如上所述的存储库。

      【讨论】:

        猜你喜欢
        • 2013-09-17
        • 1970-01-01
        • 2012-12-17
        • 1970-01-01
        • 2021-10-02
        • 1970-01-01
        • 2011-07-01
        • 1970-01-01
        • 2016-03-27
        相关资源
        最近更新 更多