概述

这是产品研发管理系列文章的第二篇：使用SubVersion进行代码管理。

介绍如何使用SubVersion的资料已经许多，这里不准备介绍如何使用SubVersion。

这篇文章主要介绍如何进行代码版本号管理。

使用SubVersion进行代码管理

• 时间区间(1)
  • (1)的起始时间是3.0开发的開始。
  • 在(1)期间。没有不论什么用户使用3.0（由于它还没有公布）。所以全部开发者直接在3.0Trunk上开发。
  • (1)的结束时间是3.0开发的结束时间。结束时公布3.0产品，在SVN上创建3.0 Tag。同一时候创建3.1 F000 Branch。这时3.0 Trunk自己主动变成3.1 Trunk。
• 时间区间(2)
  
  • (2)的起始时间是3.1开发的開始。
  • 在(2)期间，由于開始实用户安装使用3.0，所以3.1全部开发者的开发工作在3.1 F000 Branch上进行。
  • 假设在(2)期间，用户报告3.0的Bug。而且须要立即修复。那么：
    
    • 在3.1 Trunk上对问题进行修复，而且公布补丁包。
    • 将此修改合并到3.1 F000 Branch上。
  • (2)的结束时间是3.1 F000开发的结束时间。

    结束时公布3.1 F000产品。此时做下面事情：

    • 合并代码之前，在3.1 Trunk上建立Tag。如：3.0 20150601。用来表示将3.1 F000合并进来之前的代码。
    • 将3.1 F000 Branch的代码合并到3.1 Trunk上。而且锁定3.1 F000代码避免不论什么进一步的修改。
    • 从3.1 Trunk上创建3.1 M010 Branch。用于进行3.1 M010的开发。
• 时间区间(3)。(4)，(5)和(6)
  
  • 基本和时间区间(2)一样。
  • (5)是3.2的開始。

注：

1. (5)是3.2的開始。它和(3)，(4)的操作方式没有根本的差别，但有些细小的区分，主要是安排不同类型的修改。

一般我们把相对大的功能/修改放到一个新的版本号里边。(3)和(4)作为(2)的升级，主要负责修复3.1的Bug和小功能的改进。把相对大一点的功能或者相对底层的修改放在3.2里边，也就是(5)里边。

2. 究竟有多少个M0X0，由产品经理依据用户反馈的问题和待开发的需求列表决定。

3. 在一个迭代周期開始前，需求都搜集到位。我们使用的迭代周期是2个月。包含需求讨论、设计开发、測试。

注意事项

依据我们使用下来的情况。有下面注意事项：

• 假设修复Bug。能够在Trunk或者Branch上做，可是一定要使用SubVersion的合并功能，而不是在Trunk和Branch上分别改两遍。假设改两遍。造成的结果是在要将Branch合并到Trunk上出现冲突。
• 不是不论什么时候都适合进行不论什么类型的修改。

  比方有些核心数据结构的变动，将它放在小版本号升级后的第一个迭代进行。这样的大的修改得找时机，避免对用户造成升级困难。或者用户须要又一次装载全部数据。

• 在迭代开发结束是在Branch上做公布的；可是维护是将Branch的代码合并到Trunk后，在Trunk上维护。合并代码的时候须要很小心。保证Branch上的代码和合并以后Trunk的代码一样很关键。假设不一样会造成这样的情况：第一个从Branch上公布的产品没有问题；后来为了修复一个Bug，从Trunk上公布一个补丁包后。出现了第一个公布没有出现的问题。