发布版本归档问题分析

　　前段时间兴匆匆的定制了发布版本归档备份说明，大概的内容是发布版本有哪些类别／每个类别有哪些具体的版本／存储位置／存放的目录结构。当时就直接按照版本来划分目录结构了，即第一层是类别，第二层是具体的版本，第三层是对应的构建版本。今天在收集过往的版本时发现了一个问题。

　　由于归档的版本要求除了安装包,其散文件也一样要存。那么，如果归档的发布版本与安装包与安装包的散文件不是一一对应关系,就会有个困惑：在归档的备份存储位置,N个版本共用的安装包散文件该如何存放呢，这时候就不是直接将构建版本拉到第三层就可以搞定的？想来想去,就是觉得当初定的结构一点也不适用了。

附加资料：

关系说明：

1.　归档版本[1]－安装包[1]－安装包散文件[1]

2.　归档版本[N]－安装包[N]－安装包散文件[1]

目录结构：

1.　构建版本的原始存放形式：

+ 20080304.100

| | - installfile 存放散文件

| | - package　　 存放安装包

| |  |- setup　   存放特殊包

| |  |  |- A

| |  |  |- B

| |  |  |- C

| |  |  |- D

| |  |  |- E

2.　版本发布出去后存档形式：

+ 版本类别

| | - A 

| | - B　　 

| | - C 

| | - D　　 

| | - E 

改进方法：

1. 去掉第一层／第二层,直接以第三层形式存档,然后以记录形式来区分每个版本。（这是目前最优的方式）,但这种方式也有一个缺陷：如果构建出来的所有版本并不是全部要发布的,那这时候是全部归档还是去掉不发布的版本呢？

2. 如果需要归类版本的话,那直接存储安装包就可以.　对应的散文件仍在构建版本存放的位置去取。（这是个人的理想方式，不过涉及的改进范围广）