团队出现这样的场景大家一般怎么处理

不同模块开不同分支，提交之前合并，测试 不就解决了吗

任何工具和管理方式都不能保证100%不出现冲突
先down后commit，偶尔发生冲突相关人员沟通解决即可

这是管理问题，开发中的持续集成管理没做好，10人以上编码团队的合理做法：
1、持续集成频率和规则约定好，如每天上班前down最新代码，下班前提交代码，下班前系统集成自动测试一遍（前提是你的TDD工作做得够好），测试结果自动给每个人发送，第二天上班后各自修改冲突的地方，一直无法修正的问题单列并跟踪；
2、项目开发计划中，必须明确公共接口、模块间对外接口、未来扩展约定等方面的问题。
3、目前的协调职责是项目主管的，不是A或C。

若是小项目，项目主管几句话协调好就OK，别上纲上线浪费精力。

我看还是要规范svn使用、操作流程；
其次，定义什么叫开发完了，自己一个人跑着没问题，集成有问题，这能叫做完了？本身管理就存在着若干漏洞，工作态度也极其恶劣。

另外，代码随时commit，这个是毋庸置疑的。版本控制器的一个功能就是备份。如果开发机器丢失、损坏，工作全白搭了。但是，保证提交的代码能build通过，这个还是有必要的。

downpour说到痛处了，其实我昨天仔细想了下，问题产生主要源自一下几点：
1.产品本身：产品本身处于一个较为特殊的废旧立新阶段，有些地方需要推倒重来，有些需要对原有功能的进行扩充，但是新引入的组件或者模块必须很好地向下兼容，这部分往往需要架构师开始就做好一个全局的统筹，这立马引出了接下来的一个问题--管理
2.管理混乱：现状就是，没有周期的小组例会，没有真正意义的项目经理（为啥没有暂且不讨论了，离题。当然也没有严格意义的项目计划，进度控制、甚至一些规范的制定），没有真正意义的架构师，架构师在公司组织节点中跟普通程序员同级，提出措施也没有任何效力保证，所以接下来问题3产生只是时间问题
3.开发人员。每个开发人员经历、背景都不一样，架构师提倡的有时比开发人员想的还昏头，但是架构师的意义很大程度在于打造一种“开发秩序”：做什么、基于什么做、做的时候遵循什么、每个功能怎样划分里程碑、什么情况下代码可以提交等等，如果这些措施没有任何效力保证，一切只能是海市蜃楼。
所以有一阵开发，真的是按照downpour说的那样，开发一个功能点，update最新代码，集成，测试，没问题，提交。我也觉得这样按模块提交不妥，但是为了避免回到以前那个经常将svn（不管是开发还是生产环境）当回收站的阶段，多少算是点进步吧。
    感谢老抛提供的冒烟测试做法，包括scrum,有阵也研读过，大道理说出来，其实大家都很认可，但是有时做起来才发现，每个公司都会存在这样那样特殊的“国情”，令人困惑甚至苦恼。作为一名普通的开发人员，哪怕一时改变不了现状，心里多少得保留一份标尺。
    月经贴。

你这问题严重了哈，
看来带头和弟兄们有问题，这问题不解决我看你得方案1-3都不能很好得解决这事情。

同感，就目前而言，在无法短期内改善团队内部管理状况下，我只能提倡一点，其实更多是从一个程序员角度而言：自己要对自己提交的代码负责，如果我提交的代码会引起系统不稳定，不管是模块本身的问题或者原有系统接口问题，在没有就这个问题的解决方案达成任何一致的情况下，不能随意将代码提交至svn。

是人的问题， 不是SVN啊什么的问题
这个问题，我们也遇到过，大家心平气和的说一声，让A改过影响C的部分，或者两个人一起改一下。
 
  看lz的文章，感觉心气不平，估计是项目内部出现了矛盾，这种矛盾，不是靠技术能解决的，还是及早在管理上解决。

这‘谁’开始没个确定？

 

楼上误会了，没有什么心气不平，仅仅是就目前内部发生的一些问题做一些反思，对事不对人，哪怕有些事情无法更改，心里不能稀里糊涂，得过且过呀。