关于 SVN 管理的问题详细问题如下，烦请大家点进来帮我想想办法，再次谢谢大家了！

具体情况是这样的：--JavaEE
这里说的工具SVN是指Subversion

我这是一个维护性项目，所以会出现我们称呼的“版本” 根据需求开发的时间分为：周版本 & 月版本
周版本：
顾名思义为一周开发完成上线的版本，从每周一开发到周五升级至官网
月版本：
从此刻起推至一个月时间，升级时间动态定位开发时间<一月>的最后一个周五

---------------- 以下为问题现状-----------------------------------------

我们的项目环境有以下几个：

测试环境：开发完成提交svn 然后全量更新代码到该环境，提交测试组测试，通过然后至验收环境测试

验收环境：我们升级代码到这个环境目前采用的办法是将svn代码同步然后每个开发亲自合并代码到该环
境工作空间<workspace ---eclisep> 因为不能像测试环境哪样由运维将代码全量更新下来，svn上
的代码可能有本次不能升级的功能代码或是变更性代码。所以需要我们自己将本周五需要升级的
代码手动从svn上复制一份下来到验收工作空间然后打包升级至验收测试域进行测试，该测试通过
就直接升级到官网，至此基本不会出现问题了，至此一个需求开完完成到上线流程完全结束。

正式环境：使用验收测试通过的包更新到正式服务器进行常规流程测试。

至此为目前svn管理，我也知道这个根本就没有用上svn的功能
现在运维机器上由于需要开发亲自编辑代码到验收分支上，所以很多各种各样的冲突存在已经快要大面积爆发的趋势了

这里请求大家有谁能帮我解决这个问题？
我需要的理想状态是，运维处不能编辑，全部使用svn 操作将来周版本和月版本管理好，比如通过合并等操作。
目前想过一个办法是：
每个开发使用两个svn地址一个周版本一个是月版本，意思是周版本开发提交到周版本上，月版本开发提交到月版本svn地址上。但是这样缺陷是显而易见的只会操作更加的混乱和错误发生的几率。

所以请大家帮忙了！！！！！！！！！！！
谢谢大家了！！！

jianghu52

2014-05-20 09:38:20 +08:00

首先，如果成员数量小的话，建议使用git替换svn。git对于svn的一大好处在于，他是全版本同步的。举个例子：如果有一个版本1.0，a更新了a文件，这个时候如果b想提交b文件，首先他必须要先更新a文件，然后才能提交b文件变成版本1.1.

这样的好处在于很多的冲突能在开发的时候就被发现，而不用等到最后测试的时候。但是坏处在于如果开发成员的水平不够的时候，会导致很多人为一个人擦屁股的情况发生。

git的理念同svn最大的不同在于，他倾向于每个版本都是能跑起来的，都是完整的。

palmers

2014-05-20 12:16:17 +08:00

@jianghu52 你说的这个svn 也具备该功能啊我不了解git 但是svn 是可以的，开发在提交文件的时候有同一个地方被修改也会报冲突的，必须先更新然后提交尤其intellij idea自带svn这点做的非常好没有更新就提交且有冲突时是不允许你提交至svn服务器的

目前的问题是我们大家都向同一个svn地址提交代码，然后运维那边分为三个环境<测试| 验收| 正式 >
对于测试环境运维可以全量更新全部update 到本地然后打包上传到测试服务器。这没有问题。但是对于验收就行了，因为我们上传到正式环境，也就是官网的包是直接使用验收通过的包。
在这里，验收的包和测试环境的包代码是不一致的，因为如果本次不上线的代码是不能出现的验收包里面的。所以在内容里说在验收的时候需要开发亲自将svn上的代码手动合并到验收环境上然后打包上传到服务器进行测试。这样就脱离了svn 版本的控制。

hitsmaxft

2014-05-20 13:44:45 +08:00

@palmers 为每次发布创建一个分支.

假设主干是 trunk(月发布) 副主干是 branches/trunk-weekly(周发布), 每四周从trunk-weekly合并一次到trunk,验收之后完成月发布

每周从 branches/trunk-weekly copy一份,成为新分支, 比如 branches/dev-20140520

然后开发gg开始不亦乐乎地开发了, 开发完毕提交到 branches/dev-20140520 让测试mm验收.

测试mm验收完毕, 把 branches/dev-20140520 merge 到 branches/trunk-weekly , 重新回归测试, 测试完毕提交运维

月开发类似

如果有突发情况, 需要对 trunk 和 branches/trunk-weekly 进行更新, 从对应的分支拉一个新版本, 修改之后merge回去(需要merge到所有在在开发的分支)

最后, 谁往这些分支merge不需要更新的代码, 按行数罚款10块, 无上限. 完事

jianghu52

2014-05-20 19:23:11 +08:00

感觉你现在的问题并不是管理svn的问题了，而是测试环境同验收环境的匹配的问题了。
理论上来说，验收环境同测试环境应该是一致的。如果代码再测试环境跑没问题的话，就不应该在验收环境上出错。
但是看你的意思，测试环境就是普通人员的开发环境。他们会在里面打大量的log。断点。是这样么？
如果是的话。那么你这个就不是测试环境，而是开发环境了。
从开发环境合并代码到验收环境（真正意义上的测试环境）必须要手工merge的。没有其他办法。任何工具在这一步上都没办法100%保证合并的成功。

palmers

2014-05-21 09:30:00 +08:00

@jianghu52 对你说的很对理论上确实应该验收和测试应该一致而且我说的测试环境和开发环境是一致的所以我直接忽略了我们的开发环境和测试环境的代码是完全相同的。
这里的验收环境只是一个流程步骤，有时候客户需要验收就在这个环境上验收，所以有一个验收环境，平时升级为了确保功能尽可能少的缺陷所以多了一个验证环境也是为了将不上线的功能隔离开

你说的手工 merge 意思是还是避免不了手工复制粘贴代码到我所说的验收环境吗？
这个确实不是我想要的
因为这样非常的大的几率产生漏merge 多merge 或错merge