SVN, 这种管理方式, 是否合理?

[yinheli]

1. 新需求提工单, 出具需求文档, 设计文档, 审核通过后, 项目管理部同意, 并从主干新建分支
2. 当然开发只有这个分支的权限, 无其他任何权限.
3. 开发完成后, 进行自测. 然后提交测试工单.
4. 测试部进行分支验证测试, 其后进行合并主干.
5. 主干测试通过后, 排期上线.

主流程大概是上面那样. 但是开发需求/任务并行情况下, 出现了如下问题.

测试都ok, 但是代码合并到主干的时候, 因为是配置部门来做的(合并), 可能会出现代码冲突. 而开发人员本来又没有权限, 解决办法是只能开发到配置管理员的电脑上去解决冲突了.

BTW.
是的, 我是来吐槽, 不是来解决问题的. 目前在整个流程上并没有决策权.

[clino]

好重的流程...

[ZackYang]

够繁琐.

branch + CI + code review 足以.

[lxrabbit]

不是一般的复杂,就两个分支就可以了吧,一个是测试用的,一个是发布用的

[lxrabbit]

说错,是两个SVN

[fo2w]

@ZackYang
@lxrabbit
你们处理百万行级别的代码能这么玩? 是我老了吗?

[otakustay]

这不是很正常的分支开发合并主干的流程么，不知道楼上各位在吐槽啥，你们辛辛苦苦用git无非不就更多几个分支么

这个流程如果不会多个开发分支同时进行的话，理论上是不会有合并时的冲突的。如果多分支同时进行的话，让开发人员在提测前自己merge trunk

[lxrabbit]

@fo2w 原来测试还要看源码的么,我们是只让测试看到debug版本的EXE

[fo2w]

@lxrabbit 看你们是白, 灰, 还是黑盒了
而且我们测试写的accessiblity代码也有几十万行

[SoloCompany]

这是很正常的流程，但为了减轻合并出现意外的可能性，一般由开发人员直接进行
但权限控制又不好做了
反正总是会有折中的地方，看管理者更看重的是什么了

[blankfire]

如果不是看到楼主在北京，还以为是我司同事 = =！