安装包制作量大。因为我们需要做 patch 还有一些 oem 安装包。

1.脚本修改 2.创建分支、tag ，并修改权限 3.安装包制作 4.编译发布环境搭建 .......

TO: rexuekonglong 请问一下自动 meger 不会出错？ 代码不会错位吗？

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

加一个参数 -o 如： mvn compile -o

能分享一下分布式编译？

Eclipse 等 IDE 工具是由插件的支持的。每次开发自已编译都可以选择检查或者不检查

to：SQ mail 提醒只和服务器有关，client 是 linux 或是 windows 没有关系。 服务器是 windows 的不是这样的，若是要 windows 的可以参考一下以下网友的分享： http://bbs.subversion.org.cn/viewthread.php?tid=186&extra=&page=1 若是还不行，再告诉我啊。有时间可以做一个 windows 版 mail 提醒步骤。

:lol 多谢！

步骤如下（linux）： 一.编写 post-commit #cd /data/svnrepo/hooks #mv post-commit.tmpl post-commit #chmod +x post-commit

在 post-commit 填写以下内容： #!/bin/sh REPOS="$1" REV="$2" SVNLOOK=/usr/local/svn/bin/svnlook （这里使用你的 svn_home 替换） /data/svnrepo/hooks/commit-email.pl "$REPOS" "$REV" [email=cody.zhang@mycom.com] cody.zhang@mycom.com[/email] --from [email=svnAdmin@mycom.com] svnAdmin@mycom.com[/email] /data/svnrepo/hooks/commit-email.pl "$REPOS" "$REV" [email=cody.zhang@mycom.com] cody.zhang_2@mycom.com[/email] --from [email=svnAdmin@mycom.com] svnAdmin@mycom.com[/email]

二。使用 commit-email.pl 使用附件中的 commit-email.pl #unzip commit-email.zip #chmod +x /data/svnrepo/hooks/commit-email.pl #vi commit-email.pl 替换其中的,使用你自已的 svn 路径 my $svnlook = "/usr/local/svn/bin/svnlook";

三.启动 sendmail #service sendmail restart

这样就算完成，你试一下啊。有问题提问哦哦 sync: [url]http://anmanzhang.blogbus.com/logs/64827157.html/url][

[[i] 本帖最后由 codyzhang 于 2010-6-1 12:05 编辑 ]

我也要啊，持续关注:lol

版本是由项目组提交的，所以对于版本是否正确发出就有其负责，是吗？ [b] Cody[/b]： yes 最后对版本测试结果的跟踪，版本是否可以正式发行，由项目经理根据测试报告决定，是吧 [b] Cody[/b]： yes 项目经理针对版本的发行肯定会有一个正式邮件通知的吧，而配置管理应该在这份邮件的收件人列表中。 [b] Cody[/b]： 是的有个正式邮件。 发到需要通知的邮件组所有成员，包括配置管理员

版本发布触发及跟踪 角色 如何确定？ 一般发布版本是不是由项目经理触发，应该有项目计划吧？ [b] Cody: [/b] 嗯，我们这里是由项目经理触发的。通常会有计划，只是紧急项目没有计划。

至于版本发布过程的跟踪，及版本质量级别的提升又是有谁来负责及跟踪呢？ [b] Cody：[/b] 个人应由开发项目负责负责，什么样的版本可以 release，最终是项目经理来决定。

抱歉，公司现在人手不够。没有时间来处理分布式编译。不过这是很好很好的方向，有进展我发一下贴啊

好奇怪，关注。。。。。。。

我想可以定义自动更新那些 目录，也可以定义那些分支上的需要更新。 也就是只有那些需要更新的，才可以自动更新。

若是 merge 也可以，只是希望自动处理。我们的产品有点特殊，一个 release 版本，可能有好的分支，而这些分支多数都是 oem 的产品，也就是一个 bug 需要在很多个分支上修改。若是手动 merge 太花时间了，也易错！

也就是，希望一个公用的代码。一个地方所有用到的地方都更新。

我们有些公用的代码，不希望每个分支上去修改 bug。 有空了，我试一下，然后 show 给大家看哦。。。。 哈哈 不过最好不用写脚本

[[i] 本帖最后由 codyzhang 于 2010-5-18 16:14 编辑 ]

非常好。特别是备份检查这个策略。 :P

你看看访问时看看进程占 cpu 多少？ 命令： top 然后看看： 你可以用同一台 client 访问以下其他 svn ？是否也是很慢？

rexuekonglong 于 2010-5-10 14:15 发表

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

嗯，有道理哦！

to： i 子休 很抱歉我不知道你的意思是??? :) 若：你是说你们有一套系统的工作量？目前我们不是的，每台机器上可以同时搭建几套编译系统（使用不同端口），一共 5 台编译编译服务器。 若是，你指编译数量太少？这个并不是只每次提交都编译的那种，而是根据有需要就编译的那种。:) 若是，你指编译时间过短？那么是的，我们 java 项目一些只需要 20 秒。C++ 的一个项目只需要 10 多分钟。这是 CPU 有处理能力好，C++ 开发同事在自已的 PC 上编译同样项目可能需要 40~60 分钟，所以通常他们之编译一个模块。

[[i] 本帖最后由 codyzhang 于 2010-5-10 14:25 编辑 ]

哦，是这样的。我们的编译包括为开发和 QA 的两种。开发 fix 一个 bug 前需要自已在集成服务器上验证这个次数比较多。

我们公司有了一套完善的编译发布系统，可以用 2 个人支持每天 1000 次以上的编译发布。 无数次的自动代码编译、测试验证。

谢谢 laofo！ 下次不懂要请教你啊。哈哈哈.....