关于代码库结构解析

发布于 2022-09-02 08:17:44 字数 969 浏览 12 评论 0

一般而言,代码库的目录结构如下:

       有的时候,也会把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日志,我们可以轻松的记录下什么时间发布了什么样的版本,这个信息对于补丁的管理是十分有好处的。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文