转关于SVN版本管理的说明（讨论稿）

itata

转关于SVN版本管理的说明（讨论稿）
1.     参与者

所有的开发人员、软件项目经理，亦适用于实习生。

3.     目录结构

SVN的目录结构如下所示：

192.168.1.3

├─Product_A

│ ├─branches

│ │ ├─dev_1_0

│ │ │ ├─Document

│ │ │ │ ├─1需求文档

│ │ │ │ └─2测试文档

│ │ │ └─Project

│ │ │      ├─Model_1

│ │ │      └─Model_2

│ │ └─dev_1_1

│ ├─tags

│ │ ├─dev_1_0

│ │ │ ├─Doument

│ │ │ │ ├─1立项文档

│ │ │ │ ├─2需求分析

│ │ │ │ ├─3系统设计

│ │ │ │ ├─4开发计划

│ │ │ │ ├─5测试报告

│ │ │ │ ├─6会议纪要

│ │ │ │ └─7产品实施

│ │ │ ├─Install

│ │ │ │ ├─1安装包

│ │ │ │ ├─2用户手册

│ │ │ │ └─3培训计划

│ │ │ └─Source

│ │ │      ├─Model_1

│ │ │     ├─Model_2

│ │ │      ├─Model_3

│ │ │      └─Solution

│ │ ├─dev_1_1

│ │ └─dev_1_2

│ └─trunk

│      ├─Include

│      ├─Project

│      ├─Public

│      │ ├─1会议纪要(临时)

│      │ ├─2任务分配

│      │ ├─3开发纪要

│      │ └─4测试数据

│      └─SDK

│          ├─Boost

│          │ ├─Include

│          │ └─Lib

│          └─TDE

│              ├─Include

│              └─Lib

└─Product_B

每个软件产品对应SVN根目录下的一个二级子目录。每一个软件产品目录又主要包括如下三个部分：（1）Tag；（2）Trunk；（3）Branches

Tag：按版本保存该软件产品所有的经过完整测试的历史稳定版本，相当于该软件产品的“里程牌”，每个版本目录主要包括三个部分：（1）Document；（2）Install；（3）Source

Tag/Document：与该版本软件产品有关的文档，不包括组成模块的文档，相近主题的文档应保存在同一子目录下，子目录命名清晰明了，例如上图所示。

Tag/Install：经过测试的完整安装包以及安装说明、用户指南、更新记录等相关用户文档。若需要其它组件的支持也应放在此目录下。

Tag/Source：与该软件产品有关的所有源代码。Source目录下主要包括两大类。一类是源代码，主要是每一个开发人员的本地Project目录（见《关于VC2005工程配置的说明》）中的模块，每一个模块是一个目录，模块目录下包括与该模块相关的所有文档。另一类是解决方案，根据软件产品的不同，可以定义若干个解决方案，例如“XX信息平台”产品由三个部分组成：采集、应用与管理器，所以可以定义三个解决方案，分别用于生成这三个组成部分。解决方案内的工程可以按开发人员、功能等主题定义筛选器。特别注意的是，每个解决方案必须定义子工程的“依赖关系”与“生成顺序”，工程的依赖关系也需要形成文档。

Trunk：目录是软件产品当前的主干开发版本，主要由四部分组成：（1）Include；（2）Project；（3）Public；（4）SDK

Trunk/Include：软件产品开发过程中需要包含的公共头文件，不能包括开发模块输出的头文件。比如软件产品需要使用boost::share_ptr功能，该功能只包括头文件，则可以把boost::share_ptr使用的头文件放在Include目录里。Include目录也可以根据需要定义子目录，参考《关于VC2005工程配置的说明》

Trunk/Project：存放所有的软件开发模块。不同的开发人员将自己本地工程中的Project存放于此目录中，若模块数量较多注意（1）命名清晰（2）不要重名。比如功能库可以用取名“libXXX“，平台插件可以取名“pluginXXXX”等。

Trunk/Public：存放软件开发过程中需要被所有开发人员共享的文档、代码、图表等，比如项目组会议纪要、任务分配与开发计划书、测试用例数据库的dmp导出文件等。Public中的文件应该是临时性质的，不代表最终的成果文档；最终的成果文档可以由Public中的内容演化生成。

Trunk/SDK：若软件产品是基于某开发平台的二次开发产品，则该开发平台的相关文件应放在此目录下。若使用了多个SDK，则应按不同的SDK组织二级目录，每个二级目录下的文件应该是独立完整的，也应包括SDK的说明文档、更新记录与示例代码

Branches：目录是软件产品的迭代开发版本。Branches目录中应按当前迭代的版本组织目录，版本目录下的子目录组织参考Trunk目录。Branches中的内容主要由三部分组成：（1）需求文档；（2）开发代码；（3）测试结果。

需求文档记录针对某一迭代版本提出的新需求，以及为了满足这些新需求该版本的哪些模块需要进行哪些大致的调整，即“需求”；具体模块的调整方案应记录在该模块的“内部文档”中。开发代码是开发人员根据需求文档对相关模块进行调整，即“响应”。测试结果记录测试人员对修改后的模块进行测试得出来的结果，即“结果”。

“需求－响应－结果”这是一个循环的过程，直至满足了新的需求并通过测试。这个过程如下图所示：

5.     日常管理

提交到SVN的代码，必须是可Build通过的代码。特别是在开发初期，模块接口的功能可以简单地实现，或者干脆不实现，但是一定要保证依赖到此模块的IT论坛开发人员可以Build通过。

开发人员应该形成“上班update，下班commit”的习惯，即每天开始工作的时候最好是检查一下自己依赖的模块有没有更新，结束工作的时候将自己负责的模块commit。

但是这样又有一个问题，在项目的开发过程中，特别是初期，模块的接口是不稳定的，这样会造成模块的用户频繁地应对接口变化。这是应该是一个“度”的问题，也从一个侧面要求开发人员先设计接口并保证在较长的时间内接口的功能、样式保持稳定。

摘自：https://www.cnblogs.com/phoenix8 ... /12/07/1618957.html
转关于SVN版本管理的说明（讨论稿）