有效便捷的版本控制方法探讨

问题的提出：

在从事软件产品开发的过程中，我们常常会遇到这样的问题：假设某产品开发过程中出现了三个发布版本，每个版本存在部分功能差异，其余主干部分完全一致。后来发现主干部分存在1个bug需要修正，但是三个发布版本都需要修正，这为软件的维护带来很大的不方便，因为手动修正这一过程容易引入其他不一致以及错误。

解决方案的初步设想：

既然是因为同一段主干代码拥有多个不同副本导致的问题，那么我们可以让设计文件不同的版本之间的共同部分只有一个副本来解决。基于这种思想，我们可以将不同版本都统一到一个工程中来进行统一的维护。

实施细节：

在谈及实施的细节之前我们需要三个条件，具备以下条件则不同版本维护问题自然解决：

1. 良好的软件层次结构设计
2. 集成编译环境对多种工程配置的支持
3. 不同版本的宏配置文件

首先良好的软件层次设计为不同版本之间的文件结构很明朗，不会错综复杂，难于管理。清晰的软件层次主要是指综合应用程序，子功能模块以及驱动程序之间的接口清晰，数据交互不依赖于全局变量等等。比如说我们我们设计了一个产品，该产品目前的硬件平台为A，由于成本，生产效率等等原因现在需要更换硬件平台，但是功能不变。这样，新的硬件平台上的软件是由原软件发展而来的，我们可以命名新软件为第二代产品。该产品与之前产品唯一不同的地方就是驱动程序。具有良好软件层次结构的设计可以直接更换掉原来的驱动程序文件即可；相反，低劣的层次设计导致在原工程文件内将驱动程序进行拷贝修改等操作，这不但操作不便，而且还容易在拷贝过程中出错。

其次，集成编译环境对多种配置文件的支持是对前边功能的一个具体化。具备该条件我们才能够根据不同产品版本来配置工程所包含的不同文件，从而达到一个工程多个配置文件以支持多个版本的目的。还是沿用之前的例子，更换驱动程序我们可以简单的生成两代产品的两种配置实现。第一代产品中工程文件的驱动组包含硬件平台A的驱动程序，第二代产品则配置硬件平台B的驱动程序。这样我们始终保证了两代产品中一样的部分在两代产品中都得到了维护。目前大多数集成开发环境均支持同一工程多种配置，就我使用过的开发环境KEIL,IAR,CCS等均对此提供较好的支持。

最后不同版本的具有不同的宏配置文件，这一点主要用于产品识别。在这个配置文件中我们需要存放这一代产品独特的信息特征，比如产品版本号，软件修改日期等等。

2011年1月20日9:44:45添加

---

        在同一应用软件需要跨多个硬件平台时，一个更为有效的设计方法是，增加一些中间层文件，例如driver.c,lcd.c,plc.c，这些文件里边再分别include "driver.c", include "lcd.c", nclude "plc.c",然后通过对工程的不同平台配置不同包含文件夹来达到不同平台自动包含不同平台驱动的目的，从而做到不同平台统一管理。

---

实例说明：

现在以一个实际例子来说明如何使用以上方法提高产品版本维护效率和降低出错概率，同时也借此介绍一下版本控制软件SVN的使用。曾经设计过一款通讯类产品，经过几个月的工作，发布了第一个版本。(这里插入一点关于SVN与发布产品的关系：SVN版本库建立之初一般在版本库下存在三个分支目录分别名为trunk,tags, braunch. trunk是开发的主干目录；tags是开发中的里程碑式成果目录也就是不同版本产品定型目录；braunch是产品发布后出现bug的修正目录。一般我们会在每一次产品投入生产的时候将当前trunk中的开发文件转入到tags中并以版本名字建立一个目录保存起来。)

第一版本发布以后为了降低成本，提高产品通信能力，就开始投入第二代产品的开发，同时对第一代产品进行维护。当然通讯能力的提高主要是和驱动程序和硬件电路有关，因此就软件层面看来只需要更换一下驱动程序即可。在有了好的软件层次设计的基础上，我们现在仅仅需要增加一个工程配置文件将驱动程序组文件更换就能达到以上要求。在第二代产品开发过程中我们得到用户反馈，发现第一代产品设计存在一些地方不合理，因此需要进行完善和修正。按照SVN的通用做法是：我们需要第一代产品发布版从tags中分支到brunch中，然后对该版本不足的地方进行修正，最后再发布到tags中，在修正以后还要更新我们当前开发的第二代产品存在的相同问题，这就很麻烦。基于本文思想，在开发过程中我们随时都在维护公共的代码部分。因此比较好的做法是我们立即在当前的工程中使用第一版本的配置文件，然后对发现的问题进行修正修正以后导出当前工程。为了便于描述，将当前导出的工程记为P1。(为什么有导出当前工程一说？这是因为SVN版本管理的时候每个目录下边都存在一个.svn的目录记载该目录下所有文件的版本，如果不到处直接复制出去，后边的操作会出错。)导出P1以后也需要将tags中的第一发布版本分支到brunch中，然后冲brunch中下载到本地目录F1，此时我们可以直接将P1以覆盖的方式拷贝到F1中，然后上传至服务器，这就实现了对第一代产品的bug修复。当然最后就是从brunch中再次发布到tags中了。以上过程可能稍显繁复，但是倘若我们发布了10个版本，或者说对公共部分改动较大，这就显得很有必要了。因为在之后的发布过程我们都仅仅需要更换当前trunk中的配置文件，之后编译，导出，上传就可以了，不用对10个版本的每一个主干代码部分进行复杂而又易出错的修改。

当然接下来就是第三版本的开发，第三版本开发的目的是增加新的功能。为了能够保证和其他版本共同代码部分最大化(以文件为最小单元)，因此新增加的功能需要以新增加文件的形式体现。同时增加第三版本的配置文件使得其包含新增功能模块文件即可。第三版本开发过程中遇到的问题不管是之前版本共有的主干代码部分问题，还是每个版本所独有部分出现的问题我们都可以通过之前的操作方式来修复bug，因为我们trunk中的工程包含了各个发布版的最新版本。图1是一个类似以上过程的版本更新流程图，供参考。

图 1.版本更新流程图

附一些值得注意的细节:

• 每一次发布都必须修改宏文件的产品版本号。
• 每一次发布都必须要将该发布版本分支到tags中，同时以发布版本号命名目录。

  ---