• Jenkins validated merge plugin,但不是免费的。

  • 投了,等水杯,呵呵

  • 这种现象在我们公司也存在,所以,还是做新员工比较好,实在不行,我们都出去做新员工,呵呵。

  • nexus 确实挺好用,能够自动 proxy 多个 maven 库,很是方便。我是因为之前两会期间无法访问外网,被逼无奈装了一个 nexus。

  • 没用过,学习了。谢谢

  • 写的很好,但是对于文中提到的几个场景和疑难杂症并没有给出实质性的解决方案,很是遗憾。

  • 全国 SCM月薪调查 2012 at 2012年06月26日

    参与了,很想知道高薪的都是些啥公司,回头我好往那里跳,呵呵

  • maven 初级培训 (原创) at 2012年05月10日

    谢谢分享,学习先

  • 系统设置里->maven 安装中-> 新建 MAVEN_HOME,指向你自己的安装地址。

  • 而且次 job url 可以提供给特定的人,不需要专门为这人建个账号。毕竟 jenkins 的账号权限管理还是不够强大。

  • 从来没这么干过,学习了。

  • 分布式产品发布 at 2012年02月21日

    dcwang 于 2012-2-17 17:26 发表
    楼主可以试一下 puppet [/quote]

    顶!puppet!

  • 美化 Maven 报告 at 2012年02月21日

    我记得是在 src/site/ 下定制一些你需要的东西,然后报告的时候就取这里为模板。我曾经只是简单定制过 home report 的格式,其他样式啥的没定制,你试试看!

  • 从短期看,你应该同意人家用 Subversion,因为你没有好的 solution 去解决别人用 Clearcase 已知的问题的,现在强迫别人用 subversion 只能降低 team 的生产力。另外,如果的这个项目的代码跟别的用 Clearcase 的项目代码没有依赖性,是一个独立的项目的 release,暂时用 subversion 也无妨。 当然,从长期的角度看,如果能解决他们用 clearcase 的问题,在一个公司内部当然用统一的工具肯定是非常好啦,可以降低管理和维护成本,减少 resource。

  • 作为试用期员工,你提出改进,首先,你对项目组历史情况或者背景,不是很了解,提出的改进是否合理不得知;其次,你的文档结构改进,对于项目经理来说,短期或者长期看不到利益,他肯定以项目为重,拒绝你的改进,也是合情合理的。

    对于 SVN 的合并,我觉得设计到代码级别的合并,应该是开发自己做的,不是配置管理员,能用工具统一进行的。

  • SCM 工程师 360buy·京东商城 at 2011年12月31日

    每次看到工作年限是 “ 一年以上 ” 或者 “ 两年以上”,我就伤心,难道是 SCM 工程师技术含量很低,还是无需太多工作经验?:(

    [[i] 本帖最后由 马路 MM 于 2011-12-31 14:11 编辑 ]

  • 从 version history 看,2.15 开始支持附件,不过俺还没试过。因为升级 email plugin 要先升级 jenkin,动作太大,暂时没时间去做。

    [url=https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin[/url]] 2.15 (Sep 05, 2011)

    [color=red] Allow email-ext to attach files to emails (issue #9018). Default Recipients list does not appear in Jenkins global settings(issue #10783). Email to requester uses wrong email address (issue #9160).

  • 干好自己负责的部门项目,搞的有声有色,当别的部门搞不定的时候都来找你,你就可以显山露水了。呵呵!

  • 我想请客,就怕你们不愿意花路费,呵呵。(我可不在北京哦:lol )

  • 我特地去仔细读了原文,颇有体会。因为公司各个部门用不同的方式,有人喜欢用 HEAD,有人喜欢项目初始就创建分支,为了用统一他们,我要知道各个的利弊,好去说服。:)

  • [color=green] 个人观点,仅供参考:

    现在的问题是。如果你有两个任务。任务 A 和 B 并不存在逻辑相关性。 虽然理论上他们可以并行开发,但因为人手问题,任务 A 先完成了,进入 review 阶段。在同一时间,你(们)开始了任务 B,希望能利用好 review 阶段的 时间空档。这个时候,应该从什么地方开始建分支起点? [color=green][ 从你这里看,好像 review 阶段的代码不放到分支里,个人觉得开发每天的代码都应该 check-in, 这样的话,B task 应该在 A 的基础上继续进行,不需要重新创建分支,因为 A 和 B 是同一个项目上的不同任务而已。]

    又比如有一个或几个 bug,你修正了,但还没有通过 review,所以没有进入 主集成分支,而你又要开始另一个并行任务,你的代码应该是建立在修正好的 版本上,还是建立在原来的版本上? [color=green][新的任务应该是在原来的分支上进行,等 bug 确定了,再将 bug fix 代码 merge 到原来的主分支上。当然,这里有一定的工作量,但是是不可避免的]

  • 这假外企可比真外企强多了!口水啊。。。

  • 感谢分享,我也下了!:)

  • 我印象中,我曾经试用过 statcvs,它好像不能记录 branch 的代码 checkin 情况。

  • 我这里做过同样的事情,我是根据这些很冗余的 log 信息,写个 shell 脚本分析一下,把不要的信息删除掉,只留下文件,版本,日期,作者和 comments 必要信息。如:

    Working file: xxx/src/main/java/com/xxxx.java revision 1.1.2.6 date: 2011/08/08 04:16:14; author: xyz; state: Exp; lines: +28 -0 fix bug#xxxxx