d_sophia 于 2010-5-20 14:46 发表
我们现在对开 branch 和打 tag 的权限控制比较严格，由项目组提出开 branch 的请求，SCM 开 branch；而打 tag 也是由 SCM 在特定的要求下进行的，比如发布了一个版本，那就要给库上对应这个时间点打一个 tag。 分支也不是随便开的，分支一般有 ... [/quote]

这么看来，你们公司的代码策略，是单 trunk 开发，tag 发布模式。这是项目没有同时进行两个版本以上的开发而产生的现状。所以，你现在可以不动 trunk ，或者为了保证 trunk 代码和 branche 代码一致，对代码进行合并，或者用 branche 代码直接替换 trunk 旧代码。

实际上，他们准确的用词是 “提测”，而不是 “发布”。

"把 SVN 当作 ClearCase 用，当然没有 ClearCase 好用了。"

一个问题：那 CC 是否适合敏捷开发呢？ 为什么很多工作在用 CC？

你的想法很……

这样你需要写一个监视脚本，一个 merge 脚本、一个自动执行连接脚本

:lol 前两个脚本，比较耗脑细胞

:lol laofo 这个问题在下面那个帖子里，解决了:lol

:L 你那路径，你难道不知道 svn 不支持 汉语路径吗？ 你权限（auth）文件 只能写英文路径，那里面汉语路径是不行的。 你试试把 所有的路径都改成英文名字，权限文件里也一样。

另外！ 我不是高手！只不过接触 svn 才 8 个月

:lol 小 KS，不就是版本号乱写嘛，我刚入职时，就这样，乱七八糟，客户没有什么强烈反应，就是看着现实的版本号带个 alpha 不舒服。

至于上线失败:lol 差不多有两次吧，就是代码 merge 错误。

版本发布触发及跟踪 角色 如何确定？ 版本发布由产品经理、项目经理、PQA 召开上线会议决定（其重要做最后质量确认）

一般发布版本是不是由项目经理触发，应该有项目计划吧？ 项目计划要有，紧急版本可以没有，但必须有上线通知

至于版本发布过程的跟踪，及版本质量级别的提升又是有谁来负责及跟踪呢？ 版本发布过程以及质量级别的提升，当然由公司的 PQA（质量管理员）来负责

勾引咱们去培训的味道太浓了:lol

针对于第一次成功 checkout，一段时间后，update 报此 403 错误，我找到了解决方法：即 使用 switch 重新定位 svn 路径，浙江解决这个问题。（附图）

指出 2 楼的错误，你能 svn checkout 那么你的路径就是正确的，如果大小写错误，svn 是不支持 checkout。如果是无意中修改了 svn 路径，那也可以用 switch 重新定位一次路径，就可以解决。

4 楼：如果权限出错，第二条提示将不会是 request for “……”

我建议：将 svn 出错现象整理到一个小版块中，这样可以帮助好多人。 类似的 CC 等版本管理工具也可能需要。

laofo 于 2010-5-19 10:32 发表
其他分支上只要最新的版本，不会用到老的版本？

冲突了怎么办？保留最新的代码？ [/quote]

这确实是个潜在的问题，因为，代码 merge 中可能会出现不同的问题、冲突、丢失、覆盖，而自动脚本只能执行你规定的 merge 方式：一、强行 merge；二、用最新的代码文件。 如果你想自动 merge ，用自动 merge 脚本可以实现。

懒惰到不使用 merge 功能，你们真够可以的。

问题焦点分析： 一个文件，一次 commit，在两个地方同时展现 commit 操作。

svn 路径文件好只默认一个。如果修改所谓的 pro-commit 文件， 可能是徒劳无功。

还有就是，如果你想到最不得已的是写脚本，那你为什么不手动去 merge 代码呢？

[[i] 本帖最后由 rexuekonglong 于 2010-5-18 17:09 编辑 ]

看来，免费的培训确实是浪费大家的生命，内容空洞、稀少。大家洗洗睡吧……

1）一切皆当儿戏，就会出问题 2）没有通过 CM 构建，产品从研发直接到运维，这是遗留的问题。（我无能为力） 3）这是所谓的微版本（项目工作量小于 5 人/天，PQA 不予质量统计）

1）merge 之所以称为 merge，指的是合并，当出现代码冲突时，才需要考虑：use local 或者 use report 2）merge 完构建后的产品，邮件通知人员包括测试、研发、项目经理、PQA 测试库有读权限的人员包括：测试、PQA、研发（我的实际情况是研发被屏蔽在测试库之外） 3）构建活动必须经过 PQA 对相关文档（单元测试报告、codereview 报告、buildnotes、部署指导）审核之后才进行，测试人员必须发出《冒烟测试报告》证明这个版本的产品是可以进入系统测试的 4）私自构建发包，这个以前就存在的问题，我不想重复，问题已经通知我的经理（主要第二次上线结果是成功的，是容易修改的。三个月前的一个产品，因为私自发包上线，现在已经下线） 5）没有人愿意承担相关责任，因为没有人重提这个问题，最主要的是没有客户相关的重大影响。

所以，一切随风而来、随风而去。

首先，我们采用的是主干发布，分支修改 bug 和持续更新的代码策略。在研发申请系统（alpha）测试前，执行。 1）CM 负责 merge 有几个好处： a> 作为最后质量把关，又增加一个检查点 b> 防止研发随意修改代码，增加测试人员的工作量 c> 在研发人员提交代码构建同时，必须有相关修改代码的单元测试报告，以及相关 codereview 报告，这样会促使研发人员，认真对待每一次提测活动。产品质量当然也就会有所保证 2）在 merge 分支代码回主干前，封锁代码分支权限，然后 merge，提交 merge 后主干文件入库，打 tag。 3）认真对待每一次 merge 活动，用 merge 检查单，跟踪检查，最主要的就是 merge 前，代码分支的权限收回工作，一定要做到。

laofo 于 2010-5-10 14:39 发表

但是我们不能等公司发展壮大了，重大质量事故发生了才去显示 CM 的价值。

1）公司什么时候才能发展壮大，这个谁都不好说。 2）发生事故了肯定是大家都不期望的。我们不能等到那个时候才站出来。这一点想都别想。如果真的 ... [/quote]

这个道理大家都能理解，但是实践起来却是步履维艰。 两个月前，一个维护类项目，我、PQA、项目经理、研发经理一同跟踪上线情况，直到晚上 12 点上线失败。 查原因结果：代码缺失。 研发经理、PQA 结论：SCM merge 代码出错。 我的提醒：merge 代码时，研发经理在场，我要求研发经理（维护项目较小，测试工作由研发经理兼任），在代码 merge 完，对 build 结果做最后验证。 结果：研发经理没有搭理，导致代码缺失。 最后结果：PQA 定性是我的责任，我再次 merge 代码 ，构建新测试包，甩给研发经理，下班走人（时间为 0:30）。研发经理和 PQA 最后违规操作私自提交开发包给运维，重新上线——成功。

laofo 于 2010-5-10 13:11 发表

其实我感觉现在一些公司对配置管理的最基本要求很低，那就是版本控制。 这是最基本最容易产生效益，最能让别人看得见的一条。其他的好处只有当研发到一定规模才能看得出。七八个人三五条枪的可能还真的不需要配置管理 ... [/quote]

这就是我目前的情况，研发规模较小，配置管理需求中下，基本需求就是：文档、代码管理、以及系统测试构建。其他文职性工作：如流程改进、CMMI 等 都由 PQA（质量管理员）搞定。所以，公司对配置管理的重要性理解就停留在了这个低级层面上。

综上所述：一个公司的配置管理要被重视，必须有一个巨大的推动力（公司研发发展壮大、重大质量事故等）

公司重视配置管理程度与公司发展状况有关，中小型公司——发展 5 年以下的，由于公司发展的限制，研发人员数量、项目数量有限、需要配置管理人员的数量就会少之又少，（我们公司现在不到 300 人，其中只有 100 人不到的研发团队，而项目基本都是维护型代码少于 5000 行，所以配置管理员一个足够了。流程改进由 PQA 完成） 所以，配置管理能得到公司高层重视是很难的。

有可能： 1、代码提交出现问题，没有更新 2、hudson 检出 svn 路径中设置了固定的 svn 版本号

大家在操作代码库时，要谨慎。

很明显，这是种外包测试的翻版，CM 就是配置下编译环境，维护一下，最后将测试通过版本放产品库，通知发布就 OK 了

你的操作是增加，不是修改。

你 checkout 一个，改名、再提交。

:lol 我找到原因， 上面有一个已经建立的同名文件夹了:lol

:lol 先提供模板，后续再讨论

说大了，构建是一整套活动：代码、构建工具、构建环境。 说笑了，构建是一个动作，就是 “配置新手” 说的自动构建时的 “按按钮” 的动作。 我们既然说构建，当然要从大的方向上说起，所以，“自动构建” 只不过是大构建这条直线上的 一个点而已。