Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

  • Mood:

[HELP]求助:公司的源代码版本管理

公司有两个产品(A,B)公用一个代码基。我是说,虽然软件的模块化已经做得很不错了,两个产品各有 20 个左右的模块,但是主执行程序是一个很大的可执行文件,并没有拆开,而且每个产品也会借鉴彼此的其他模块,引用功能。因此,在代码仓库中,代码是存放在一起的,编译和打包时的过程和内容也相似。问题是,两个产品的发布周期不同,而且在发布时有 patch release 和 full release 两种,前者的频率比后者要高,后者的开发可能有多个分支同时进行。这样的情况下,源代码应当怎样管理呢?


目前使用 VSS 管理代码。代码维护方式至今变了两次。

在正式 release 之后,采用的做法是原来的代码树专门用作开发,另外复制一份代码树用作后续的 patch release。

然而,后继的 full release 并没有使用原来的代码树,而是使用了与 patch release 相同的代码树。原来的代码树一直保留到现在,有非常多新代码,但是处于停滞状态(被放弃了)。

在这次 full release 之后,停用目前的代码树,新开辟两棵代码树,一棵用作 patch release,一棵用作 full release。但是,新的代码树不会复制所有代码,而是只保存自这次 full release 之后变化的代码。

然而,目前所有的代码都必须同时提交到 patch release 和 full release 中,保持两棵树的一致,因为编译步骤是 “先取原完整代码树 T1,再取 patch release 代码树 T2,最后取 full release 代码树 T3”。这种状态几乎是前一个“然而”的翻版。“只保存变化的代码”徒然增加了提交代码时的郁闷程度。我觉得这回的 T3 可能又将放弃了。

问题很讨厌。一月内就要 full release,但是几乎所有人对代码应当提交到哪儿都有自己的看法,做法也不一样。我早就建议有专门的 build manager,然而现在的仓库维护是多头管理:自己的项目随意命名,搞的新项目没法命名;几个领导随意决定代码树的配置。

还有个问题,如果同时开发两个 full release 的内容(我们在三月份还有一次 full release),开辟另一个代码树,如果这棵代码树只保存增量,怎样保证它可以编译?这棵代码树什么时候可以切换到主代码树(将前次 full release ,以及自那以来的所有 patch release 的结果合并进来),或者应当将这棵树合并到什么地方去?

有什么好办法没有,这种问题在 VSS 的前提下能否解决?
Tags: 工作
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments