搭车晒我的问题哈： 1.目前看来我们产品主要有两种文档：设计文档和帮助文档。帮助文档应该是肯定入库的，是随着产品的增长而增长的；对于设计文档，产品的每个不同版本都对应了不同的设计文档，可能这个版本的产品还没有开发完成，还没有发布，下个版本的设计文档已经开始了，如果设计文档入库的话，这个时候该如何管理？如果不入库的话，设计文档又该如何管理呢？ 2.安装资源入库。打安装包的时候有很多资源需要打入安装包，这些资源大部分是不经常变动的，目前有一部分是本地修改维护，但是我认为，这些是属于产品的一部分，也是应当入库管理的。

就像 5 楼 scmroad 说的，你把你开 v1.0.0 和 v1.0.1 时项目的状况给介绍一下。 考虑这么几个问题： 1、开分支 1.0.0 的时候，项目是不是已经趋于稳定，也就是说，此时离发版本之前要做的时候就只剩下修复 bug 了，等 bug 修复到一定程度后，merge 回 trunk，构建发布？ 注：此时的 1.0.0 的 branch 如果最终从分支发布的话，那么严格意义上，它就是一个发布分支。 2、开分支 1.0.1 的时候，是出于什么目的呢？是不是为了新的 feature 的开发？如果这个 feature 不能进 1.0.0，这就意味着，在 1.0.0 发布之前，这个 branch 几乎不能 merge 回 trunk。 3、是不是不进行任何基于 trunk 的开发，只用于构建从而提供测试产品？这样的话，整个产品的发展方向是怎么确定的？

呵呵，个人简介，仅供参考！

你是怎么用命令的呢？ 比如说启动 apache server 的话，可以这样用： 1、到 apache 的安装目录 %INSTALL_DIR%/bin 2、./httpd(注意这里要用 “./”，如果不是 root 用户的话，可以再试一下 sudo ./httpd)

试试看，希望有帮助！

在 apache 的 httpd.conf 里面加就可以了。

问题解决啦。。。 1、造成 email 相关的 module 不能安装的原因是公司封掉了有 email 关键字的网站（多谢 xiaoxiang 同学提醒）。 2、所有环境准备好之后 bugzilla 还是不能正常访问，apache 里面抛出错误如下 [Wed Jul 07 11:41:20 2010] [error] client 192.168.128.199The system cannot find the path specified. : couldn't create child process: 720003: index.cgi [Wed Jul 07 11:41:20 2010] [error] client 192.168.128.199The system cannot find the path specified. : couldn't spawn child process: D:/bugzilla-3.6.1/index.cgi [Wed Jul 07 11:41:38 2010] [error] client 192.168.128.199The system cannot find the path specified. : couldn't create child process: 720003: index.cgi [Wed Jul 07 11:41:38 2010] [error] client 192.168.128.199The system cannot find the path specified. : couldn't spawn child process: D:/bugzilla-3.6.1/index.cgi 上网查了一下，在 config 里面加上 ScriptInterpreterSource registry， 就可以正常访问啦。

非常感谢 fofo 同学的极力帮助:handshake

基线提升 builid 出来的版本对应一个个 tag，这些 tag 就是一个个的基线，从这些 tag 里面通过功能测试、性能测试等一系列测试之后，比如确定 tag1 对应的版本为 milestone1， 把 tag1 提升到 milestone1（milestone1 中可能有 tag1，tag2、、、）；再通过审核验证，最终确定 milestone1（或者从 milestone1 包含的多个 tag 中选出一个）对应的版本作为 release GA 版本。这个过程可以形象的说成是基线提升过程。 其实它就是基线价值的一个认定过程， 通过一系列的检查和验证活动，不断的确定基线的价值， 最后选出最有价值的一个基线作为后续的工作基础，或者作为最终的发布版本（比如产品线）。 打个比方，一个个基线对应着苹果的不同生长时期的一个个快照，通过一些标准来检查验证每个时刻苹果的生长情况，比如说大小、色泽、还有味道吧:loveliness: ， 然后确定哪个时刻的苹果最适合采摘。

[[i] 本帖最后由 d_sophia 于 2010-7-2 09:40 编辑 ]

re：12＃ 13＃ 这个分支是我接手后才了解到的，从分支的名称上看，应该是作为 fs 分支开出来的，后来开发人员的注意力全部集中到了分支上，而 trunk 实际上已经停止活动了。当然，这个项目是单项目，而且开发团队不大。

现在开来，这个分支的作用已经由当时开的时候的 fs 转化成为 release。呵呵，暂且不说开这个分支的目的和它是否达到当时的目的，如果项目计划和设计做的不是特别到位，而对开始开发之后的情况预测又有很大的出入，那像这种转换也难免存在，我们是否需要考虑扩大规则，允许这种情况出现，而且能够提供一套有效的处理方式呢？当然我现在的处理方式是把 trunk 打一个 tag，然后把分支上的东西拷过来作为 trunk， :L 这样的话又多了一类 trash 性质的 tag。

版本的发布触发严格意义上应该是由项目经理触发的，并且应该有制定好的发布计划。

我们现在决定要发布新的版本时，会出一套 fs，开发人员根据 fs 开发，测试人员根据 fs 进行测试，到发布版本的时候根据开发测试结果确定 fs 在发布版本中的取舍情况。在开发过程中，有配套的 bug 跟踪，最终的 bug 修复情况也是发布的一个重要参考依据。

我觉的楼主的主要问题应该是：配置管理做了不该做的事情，对基本的变更控制、质量控制做的不到位，或者没有明确的过程。

发布管理根据配置管理、变更控制过程、质量控制过程的反馈信息确定发布版本。

我们现在对开 branch 和打 tag 的权限控制比较严格，由项目组提出开 branch 的请求，SCM 开 branch；而打 tag 也是由 SCM 在特定的要求下进行的，比如发布了一个版本，那就要给库上对应这个时间点打一个 tag。 分支也不是随便开的，分支一般有功能分支、发布分支、patch 分支，相应的开发人员在相应的分支有特定的权限。分支会在完成其使命之后消亡，比如发布分支在产品发布之后消亡，也有发布分支在产品发布之后被留下的情况存在，这点我们存在着一些争议， 一方面认为留下发布分支是考虑到之后基于这个发布分支继续新 fs 的开发； 另一方面认为发布分支在发布后会有相应的 tag，如果要基于这个发布分支进一步开发，可由 tag 再开出相应的分支（我支持这一点）。 我们也遇到一种情况，开发小组在分支上进行新的 fs 的开发，最终在分支上进行版本的发布，回头在看，发现 trunk 上的东西已经好久没有动了，trunk 对他们来说已经没有用，所以他们要求废弃现在的 trunk，把分支上的东西转到 trunk 上——分支和 trunk 的转换。如何才能有效的实现这样的转换，思考种。。。

细细看过，还是比较全面，帮我梳理了一下 cm 计划涉及到的东西，呵呵！ 不过还有一些不明白的地方－－－－－

似乎没有见到如何确定基线，何时打 tag（是否这些问题已经比较细化了，楼主没有列出）？ 是在项目计划里面制定基线里程碑计划还是在分支管理模式里面？

项目的构建中的版本命名规范是要 cm 确定，构建脚本的存储方式也是由 cm 确定，但是构建脚本的说明以及如何构建是否是要负责构建的人详细制定呢？

tag 记录了分支删除前所有分支上的配置项的一个状态。 不如你在 svn 里面试试，呵呵。。。

“消亡” 就是删除掉，呵呵！ 一旦一个版本发布出去了，那对应发布的版本会在 tag 库里面有相应的 tag 来记录发布出去的东西。而且，如果对使用了能够记录历史数据的版本控制工具（例如 SVN），那要准确的重现配置库的历史也应该不成问题的吧。不过要把发布出去的东西准确的备份起来，我认为还是打 tag 比较好。

如果把发布分支留下来，那是不是以后的维护都是基于这个发布分支来进行？像第一个 hotfix 在发布分支上修正了，那第二个 hotfix 来了是不是要在第一个修正的基础上继续修正？如果是这样，那某一客户他仅仅需要第一个 hotfix，也就是说他需要一个 patch 来解决第一个 hotfix 中解决的问题，但是第二个 hotfix 修改的代码和第一个有重叠，这种情况该如何处理呢？？

如果有基于版本的 hotfix1，从版本开一个分支，修正完成之后将该分支打 tag，然后把分支删除掉，就像发布分支的做法一样。那以后如果有基于 hotfix1 的 hotfix2，那就可以基于 tag 库里面的 hotfix1 的 tag 再开分支，发布后再 tag，删除分支。

就像你说的，每个公司发布 hotfix 的方式不一样，需要根据实际情况来变通吧，呵呵！

对，是从 release 分支打的。 只是现在我们还有一些分歧，等到版本发布了以后，这个 release 分支是否该消亡。 在你推荐的文章里面，当 trunk 作为开发主线，针对每一次发布都会在项目发布前期开一个发布分支，而这个发布分支是一直留下来的。 但是，项目开发时间长了以后，谁能保证这个发布分支上的东西的准确性，而且，发布掉的版本在 tag 库里面都有对应的 tag，后期的维护可以随时从 tag 库里面开分支，修 bug 等。公司现在要给客户打 patch 也是基于客户使用的版本发布时的源码来修正 bug 的。所以，我认为发布分支在版本发布之后就可以消亡。

确切的应该说 Git，Mercurial 是那些开源软件开发人员比较青睐的两个版本管理工具。－－－laofo 的表述更准确。

我们公司是做产品开发的，在开发过程中更趋向于第一种分支模型。每 build 一次就会在 tag 库里面有一个 build 的标记，然后对 build 出来的这些版本进行测试，当达到了发布里程碑的时候，对 build 出来的版本通过测试提升它们的价值，最后确定出要发布的版本。

如果在对 tag 库里面的 build 版本进行测试的过程中发现了 bug，那就基于 tag 库里面的 build 版本开 branch，修改 bug，当修复完成之后，从完成的这一点打一个 tag 到 tag 库，然后进行进一步的测试，提升版本的价值，直到确定为发布版本。

在配置管理中，审计的一个主要方面也就是基线审计，通过对基线的不断审计，不断的推进基线，直到有一天，基线达到了设定的某一个里程碑的要求，那就说这个里程碑被达到了，此时的基线转化成了里程碑基线，当然这种审计是严格义意上的基线的确定。像我们公司现在做了自动化构建，每次构建成功之后就会自动打一个 build 的 tag，这种构建成功也可以说是一种审计，其实确切的说是一种验证，是对代码整合之后的能否通过编译的验证。

其实工具的选择主要是根据开发团队的具体情况而定，没有最好的，只有最适合的。 Git 和 Mercurial 能够很好的支持分布式的开发方式，成为众多开源软件开发者和海内外协作开发者的最爱。但是对于只有一条软件开发线，进行集中式开发的团队来说，subversion 无疑是目前最好的选择，支持并行开发、事务性提交、重命名等等，最主要的，免费的哦:lol ，目前已经到了 1.6 了

把删掉.svn 文件夹所在的文件夹删除掉，cleanup 整个工作空间，update 整个工作空间，然后再 switch 就 ok 啦！ 在 switch 工作空间前要确保你要 switch 的目录下的本地工作空间内容和库一致，否则就会出错。

但是,我们并不是当要发布项目 A 的时候再拉出 release line,我们是一开始就拉出这条分支 (叫作项目 A). 开发人员主要在主干 (Main line 或者 trunk) 上工作,他们作的东西很多,我们让开发人员只把包含在项目 A 中的 feature 放到 Release line(项目 A) 上去.－－－－－－－－－－－－ 我的一点想法：： 开发人员可以一直在 trunk 上工作，并且及时的构建，将构建版成功的版本都打 tag；也可以选择性的打 tag，然后对构建好的版本进行验证，如果确定满足了发布条件，并且确定为 rc 版本，就可以进行进一步的验证，发现 bug 的时候，可以基于 rc 版本的 tag 开 branch，修复 bug，直到版本的发布。 至于新的 fs，可以规划进入下一个版本。也就是说，当确定要发布版本的时候，它所应该包含的 fs 都已经确定。

对于我们的项目来说，每周末向外部连接测试的下一个 cycle 发布的代码都可以采用集成分支的方法。目前因为每次发布后如果出现错误在主干上直接修正，所以没有用分支，而是采用标签的方法标注每一次发布的内容。------------------ 如果发布后错误直接在主干上修正，那假如 a3 发布后出现的错误在主干上修正了，a3 之前的发布掉的版本 a0，a1，a2 也出现了同样的错误，而这些版本都是客户正在使用的，要如何来修正呢？