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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 3622 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

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

svn

版本

代码

13 条回复 • 2014-05-22 23:58:03 +08:00

hitsmaxft

2014-05-20 00:29:02 +08:00

svn有个一个功能, 叫做分支, 看你们这些操作明显就没这个概念, 还要拷贝文件之类的
分支操作还分机器这点也完全没法想象.

先瞧瞧这个 http://www.subversion.org.cn/svnbook/1.4/svn.branchmerge.html

直接checkout一个分支打出个war进行验收和发布不就完了.

另外, 你的语文怪怪的, tw人?

jsonline

2014-05-20 00:46:00 +08:00

@hitsmaxft SVN 的分支很鸡肋，跟 Git 相比。

cyokvip

2014-05-20 08:07:32 +08:00 via iPhone

的确，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:07:27 +08:00

@hitsmaxft 直接checkout 和全量更新没有区别，而且，里面包含了我不想更新的代码

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块, 无上限. 完事

hitsmaxft

2014-05-20 15:43:32 +08:00

@jsonline 我们团队在svn上分支管理用得也挺欢的, 到后来切git毫无压力.

还是团队对源码管理的认识程度问题.

palmers

2014-05-20 18:46:21 +08:00

@hitsmaxft 你说

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

这个是新建文件夹吗？这样合并的时候更麻烦啊？分支让svn 创建管理能达到你这个想法吗？

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

hitsmaxft

2014-05-22 23:56:00 +08:00

@palmers svn 的分支管理本质就是文件夹复制, 如果你觉得这不能解决问题, 那么也没必要用 svn.

本来你就不应该信任 merge, 用 codereview 和回归测试才能保证每次开发的正确性

hitsmaxft

2014-05-22 23:58:03 +08:00

svn 的分支管理我上面的链接里面有, 先弄清楚svn 的工作原理, 否则认知不一致没法交流.