适用于不那么聪明的程序员的源控制系统

Question

问题:

一个庞大的代码库,跨越数百万SLoC,由大量的第二/第三速率程序员(大多数人并不关心)维护(支持/主动增强等).几十年前,很少有智能人员使用下面使用CVS的包装器,当前这一代开发人员正在使用该系统(其中90%的人没有直接使用CVS,或者听说过/使用过另一个命令行源控制系统) .

效果:

使用CVS和跨多个模块的多个团队,不可避免地=> CVS分支合并到主干.这将是一种以最虔诚和仪式可能的方式实践的活动.[=>蛮力; 计划好几个星期,涉及十几个人2/4天.手动处理数百个(有时数千个)源. 有趣的是,涉及的人不是修复的原始所有者,他们只是通过检查差异; 真的,不是在开玩笑!这导致库/模块/功能的完整性存在很多不一致性,并且在这些合并期间花费了太多精力来纠正由于回归导致的缺陷.

而现在,问题是:

什么替代源控制系统可以带来一些积极的变化,并改善程序员/经理和环境中的其他人的生活？

由于身边的每一个人似乎都醉KoolAid(同唱"这 - 是 - 如何-事情,是全熟,处处"),甚至没有给出关于寻找一个替代一想,是时候有人做到这一点.但考虑到那些使用该系统的人,应牢记以下几个方面.

1. 简单易用和理解,甚至Joe Coder应该能够毫不费力地使用它.(无论如何这不需要,因为包装器会隐藏真正的引擎盖下的东西)
2. 一个巨大的代码库(由多种语言的源组成),在任何给定时间都有多个(大约30个)活动分支.
3. 轻松融入各个分支机构.(考虑到变化量非常大)
4. 如果可以的话,对该系统的商业支持将是甜蜜的.
5. 开发在UNIX服务器上进行(至少应在HP-UX/Solaris上运行)
6. 应该很好地扩展(数千个用户/数十万个来源)
7. 好文档
8. 简单/清晰的基于浏览器的界面,用于比较/查看更改/副本.
9. 存储库中没有二进制文件,因此无需担心它们.
10. 将当前存储库内容导入新系统的规定.

所以,请建议.有希望&&出路吗？:) 我很确定像git这样的东西会被彻底拒绝(他们相信"git只适用于聪明的人")

编辑:我也考虑过Mercurial和BitKeeper,并向链接人员提及过它.希望最好的!谢谢!:)

Answer 1

你可能听过关于好,快,便宜的古老谚语.这同样适用于此.具有丰富的功能集会带来一定程度的复杂性.我不相信你可以在不选择涉及某些复杂性的工具的情况下满足要求列表.我祝你好运,但如果是我,我会选择一个好工具并投入一些时间来培训用户.