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

以功能为单位持续集成
开发完成一个功能update svn， 经过严格测试后没有问题然后提交。

提交的功能如果有问题 有严厉的惩罚措施（华为就是这招）
小样 看你敢不敢随便commit

既然， 你看到了， 我再多说几句吧：

1。 统一IDE开发工具， 统一SVN客户端版本<包括ide的SVN插件的支持版本， 开机器SVN版本>。
2。 使用统一的代码格式化工具。包括XML, java code。

如果这些能做到， 代码冲突的机会将会减少很多。我怎么也想不明白， 为什么会有大规模冲突，这一般是不大可能的， 不要说我没有参与大规模项目开发， 让根据冲突的原因，制定规则才是最重要的。

另外， 版本控制使用是程序员的基本素质。 还是要花心思培训的。 目前， 我们的规则执行下， 基本每个不到一次的发布编译冲突。 把冲突按步骤，一点点解决。
没有一个工具能解决冲突问题， 那些某些说的天花乱坠的SVN工具也未必是好事情。

js 库 jar包怎么能够让人随便就上传呢？
要架构师干啥？
项目初期就定好的东西 即使要加新jar也要架构师点头
开发人员就不应该给上传jar js等的权限（不知svn能控制这么细不？）

可以控制的很详细。 不过要有支持工具， 我们用的时候还没有好的支持工具， 我们是自己的做了一个。

分布式源码管理才是将来的出路
别整天想着大一统就万事大吉

还是把合并代码冲突作为一个工作
而不是一个错误来作吧.
反正已经大规模了.

PS:只要提交的代码够细.
出冲突解决越简单.
简单的事人人喜欢干.

每个程序员需要保证自己的代码没有编译错误，才能提交到代码库。

关于代码提交的规范问题，我的建议就是及时检查每个人的提交，如果提交注释写的不清楚的，就跟他指出，而且必须是测试通过的才能提交。见到一次说一次，烦死他。

另外，容易出现冲突，跟设计和任务分配不好也有关系。负责这方面工作的人本来就是要使下面的开发人员的工作变得简单。

关于别人要使用自己的代码时的那种提交（即没时间经过完整的测试，仅仅为了传代码，不能作为一次提交版本的），使用git作版本控制可以解决，不过好像现在在windows上还不太好用。而且git用起来更需要“学习”，有一定代价的。

开发一个免费的CC就比较好解决问题了。

刚跟上头提一方案，大体想法是建个分支出来，一个主干，一个开发分支，平时所有工作都在开发分支进行，然后每次由架构师牵头，有选择地将开发分支的功能合并到主干去，对外发布，一律取主干。结果惨遭否决，理由是嫌合并麻烦，my god。