关于代码库结构解析

一般而言，代码库的目录结构如下：

       有的时候，也会把release目录命名为tag，之所以按照这样的目录结构来命名是有缘由的，下面是我个人的一些理解，供参考。

       任何一个项目/产品都会经历一个从无到有的过程，在这个过程中，我们会使用Trunk这个目录，当产品达到发版要求时，我们会将发版那一个点的代码做一个Tag,放到release/tag目录（由于项目不同，其目录结构也会有所差异），这是一个静态的点。比如，当GCL2008发版时，我们会做一个Tag,以捕捉625的环境一部分（这里只包括源码，最好打版本的脚本也能够在这里），并没有开发环境（比如Dephi）。

       当同时需要开发两个版本或对源码的改写不是那么确定时，我们就需要做一个Tag到Branch，其实这个Branch的作用与Trunk类似，也是一个动态，代码会在这里不断演进。比如GSP的升级，因为有很多不确定因素，所以我们需要做一个Branch,以防止不确定性问题的发生对项目造成的影响，如果没有发生问题，我们还可以将其合并到主干（Trunk）版本上。

       大家可能认为Branch、Tag是一样的，最容易理解就是Tag是一个静态的过程，而Branch是一个动态的过程，代码是一个不断演进的过程。

       对于配置管理员而言可以解决一下几个问题：

1、 版本发布环境一部分的备份（这里只针对源代码和Build脚本）；

2、 对于后期的用户反馈以及补丁制作提供了有力支持（Branch）；

以上我对配置库目录结构进行了解析（在这里并没有包含版本管理的思想），下面我就对SVN的版本管理做一个简单的介绍，利用Log日志，我们可以轻松的记录下什么时间发布了什么样的版本，这个信息对于补丁的管理是十分有好处的。