关于分支的版本标识与合并管理

rebeccazxy

我们组织对以前项目的分支管理没有形成统一的说明和规范，于是各个项目各成一统，现在要发展产品线，线上的项目越来越多，配置管理员对分支的统一管理迫在眉睫。

由于以前没有做过分支的标识和合并管理，所以这块是一头雾水啊，请大家指教。

以Readme.txt这个文件为例，附件是其版本示意图：

版本标识的问题包括以下几个方面：
1. 从示意图中可以看到Readme.txt这个文件在主干上发展到1.2时，我们对其打了一个基线，那么这个基线如何标识？
2. 在1.2版本时，建立了一个分支“主干的分支1”，这个分支怎么标识？
3. 分支1发展到1.2.2.1时，我们对其建立了一个基线“分支1的基线1”，这个分支的基线如何标识？
4. 分支1发展到1.2.2.2时，对其又开了一个分支“分支1的分支1”，这个分支的分支如何标识？
5. 主干继续发展，分支1的版本1.2.2.2要合并到主干的1.4版本上去，形成了1.5版本（这个不知描述是否正确），那合并之前的两个版本如何标识？合并之后的主干的版本如何标识呢？

以上的情形是我设想的，主要包括了主干的基线、主干的分支、主干的分支的基线、分支的分支、合并前的版本、合并后的版本几种情况的标识，请大家赐教。

另外，不知道大家都用什么工具来管理版本的演化呢？我感觉用excel管理很混乱啊！希望能够通过标识看的比较明了，但是还没有找到合适的标识方法。


上一篇：Subversion培训教程
下一篇：编号和标识的区别

iamredeye

没明白"基线如何标识"是什么意思，这个“标识”指的是什么？

也没明白“管理版本的演化”指的是什么，是指管理各个版本包含什么内容（比如功能）吗？

rebeccazxy

原帖由 iamredeye 于 2008-5-21 15:48 发表
没明白"基线如何标识"是什么意思，这个“标识”指的是什么？

也没明白“管理版本的演化”指的是什么，是指管理各个版本包含什么内容（比如功能）吗？

1. 可能我没说清楚，我说的标识指的是标识符。比如当我们没有引入分支管理时，我们的基线标识可能是bl_01之类的，当引入基线后，这样的标识显得有些简单，我希望能够通过标识一眼能看出是主干的基线、还是分支的基线、或分支的分支的基线....
2. 我说的“管理版本的演化”，主要是配置管理员自己心中得有这么一张图：什么时候建立了分支，这个分支发展到什么时候建了基线，这个分支什么时候跟主干的什么版本合并了，合并之后是什么版本等等。
哦，对了，那个图只是个示意图，或许吧Readme.txt改为一个代码集合更恰当。
不知是否描述清楚......

iamredeye

明白了。但不太理解你的困扰在哪里。

标识不难吧，主干用得标识的位数和分支完全不同，他们之间的继承关系也很容易从数字上看出来。你这张图上也很清楚的，至少我就能看明白。

关于分支的合并，这个应该是project level计划好的，比如从那个版本出来，什么时候合并，合并到哪个分支。相对的主干配置管理员应该只是看到标签后具体操作。我不明白的是你想要的东西好像就是你画的这张图嘛，我觉得很清楚啊。如果整个分支结构非常复杂，我想不同级别的分支一般是有不同的人来负责维护的。比如central肯定有专人负责，project level也可能有自己的配置管理员，每个开发人员对自己的分支负责。整个流程定义清楚了大家就各司其职，只用关心和自己相关的那几个分支。

至于合并后的分支如何标识就取决于变更的大小及公司的产品策略，比如可以从1.3到1.4，也可以直接到2.0。

或许我没有理解你的意思。。。

rebeccazxy

原帖由 iamredeye 于 2008-5-21 20:32 发表
明白了。但不太理解你的困扰在哪里。

标识不难吧，主干用得标识的位数和分支完全不同，他们之间的继承关系也很容易从数字上看出来。你这张图上也很清楚的，至少我就能看明白。

关于分支的合并，这个应该是proj ...

多谢答疑！！:loveliness: :loveliness: :loveliness:
我的困扰有两个方面：
一个是标识，比如主干的基线和分支的基线都怎么标识的？比如主干的分支和分支的分支怎么标识的？我图上的0.1、0.2、1.2.2.2是版本工具自动生成的版本记录，而不是我想要的标识，我说的标识是人为规定的标识方法。
二个是管理，我现在关注的不是project level的管理，而是product level的管理，也就是说不是项目级别的，项目级别内的变更我也不关注，我关注的是整个产品线的演化。所以我需要一张表格或图示（具体什么形式我没找到合适的，也正是要求助的）来描述版本的演化，或许这个图描述的比较清楚，但是它只是我凭想象虚构出来的，我不知道大家都是用什么方法来管理的？

iamredeye

ok，现在我明白了。

这个标识就是变量名嘛，比如你可以命名Rel_2.5_xxx; Prj_2.51_xxx; Dev_2.511_xxx等等，清楚就行了，这个应该不是什么问题吧？

至于product level的管理，首先是有product level的CM plan，哪些prjoect什么时候integrate在什么branch。至于这些project branch下面的分支就不用管了。有了这个plan怎么画出来比较清楚就很容易了，你这个图也行啊，用excel应该也没啥问题吧。

iamredeye

哦，你们以前没有product的统一管理，也就是说project之间协调不够。那么现在如何协调所有项目的scope和schedule是一个尤其要关注的地方。那么PM及以上的managers要“坐在一起”好好商量一下这个CM plan了

你的困惑大概是在CM的操作层面，但我觉得问题关键是在管理层面，就是product mgmt比较单薄，目前说尤其是planning

[ 本帖最后由 iamredeye 于 2008-5-22 12:56 编辑 ]

rebeccazxy

原帖由 iamredeye 于 2008-5-22 12:54 发表
哦，你们以前没有product的统一管理，也就是说project之间协调不够。那么现在如何协调所有项目的scope和schedule是一个尤其要关注的地方。那么PM及以上的managers要“坐在一起”好好商量一下这个CM plan了

你的困 ...

谢谢哦！
从你所有的解答看出来，你比较强调plan，也就是说在做产品的CMP的时候就已经规划好了何时分支何时合并，是吗？那这个管理起来就相对容易了。
我想问的就是你说的变量名的问题，不知你们的命名规范是怎样的呢？谢谢啊

iamredeye

CM的重要性本来就在于它对product和project planning的支持。即使你们先有project后来开始发展产品线，也一样的。

我们公司的命名规范我也不清楚。不过我不认为这是一个值得讨论的问题

xixiaojing666

原帖由 rebeccazxy 于 2008-5-21 14:19 发表
不知道大家都用什么工具来管理版本的演化呢？我感觉用excel管理很混乱啊！希望能够通过标识看的比较明了，但是还没有找到合适的标识方法。

我们目前就是用的EXCEL，我觉得有些复杂和分支多的时候，标识也许就不是万能的拉。此时可能需要标识+版本演化图。。。才能表示清楚。

xixiaojing666

原帖由 rebeccazxy 于 2008-5-21 14:19 发表
版本标识的问题包括以下几个方面：
1. 从示意图中可以看到Readme.txt这个文件在主干上发展到1.2时，我们对其打了一个基线，那么这个基线如何标识？
2. 在1.2版本时，建立了一个分支“主干的分支1”，这个分支怎么标识？
3. 分支1发展到1.2.2.1时，我们对其建立了一个基线“分支1的基线1”，这个分支的基线如何标识？

关于版本标识的问题，我觉得你可以参考你以前的标识，其实别人的未必是好的，适合你们自己的才是最好的，给你举个小例子希望对你有帮助:)
基线标识：PG[1.0]（PG表示编码阶段）
分支标识：BRA[1.1.1]（1.1版本上的一个分支）
分支的基线标识：PG-B[1.0]（-B表示是分支）

rebeccazxy

原帖由 xixiaojing666 于 2008-5-26 15:17 发表


我们目前就是用的EXCEL，我觉得有些复杂和分支多的时候，标识也许就不是万能的拉。此时可能需要标识+版本演化图。。。才能表示清楚。

我能想到的比较好的记录方式也就是版本演化图了，对你们用EXCEL管理的方式很感兴趣啊！不知是怎么记录的呢？是图和表结合吗？

rebeccazxy

原帖由 xixiaojing666 于 2008-5-26 15:36 发表


关于版本标识的问题，我觉得你可以参考你以前的标识，其实别人的未必是好的，适合你们自己的才是最好的，给你举个小例子希望对你有帮助:)
基线标识：PG[1.0]（PG表示编码阶段）
分支标识：BRA[1.1.1]（1.1版本 ...

标识这块我之前是零，没有涉及到分支之前，标识基本就是V1.0、V2.3等等，基线标识也就是bl_req_01等。一上分支就感觉有点晕，怕不够用，特别是涉及到主干的基线、分支的基线时，就有点怵......
静JJ的例子很有帮助哈，我就是想看看大家做标识的时候都考虑了哪些方面，比如分支标识：BRA[1.1.1]，很明确就能看出是1.1版本的分支，是此版本的第一个分支（如果没有理解错误的话），谢了！

nicezfish

好的配置管理工具可以提供给楼主一些配置原理，基于这些配置原理再实际的操作会比较好，毕竟工具是在方法上抽象出来的合集，对于使用工具不仅仅是对配置管理的人机的结合高效使用，更注重规范在实际中的部署！

loosiech

好文章，借鉴一下