适用于不太聪明的程序员的源代码控制系统
问题：
庞大的代码库跨越多个 百万 SLoC， 维护（支持/主动增强 等）由一群二流/三流 程序员（他们中的大多数人不 真的很关心）。几十年前，聪明人很少 伙计们已经放了一个包装纸 底层使用CVS，这个系统是 当前一代正在使用 开发者（90%没有使用过 直接 CVS，或听说过/使用过另一个 命令行源控制系统）。
效果：
CVS 和多个团队的使用 跨多个模块工作， 不可避免=> CVS 分支合并到 树干。这将是一项活动 以最虔诚和最虔诚的方式实践 仪式上可能的方式。 [=> 蛮力；提前几周计划， 涉及十几个人2/4天。手动处理数百（有时数千）个来源。 有趣的是，所涉及的人并不是该项目的原始所有者 修复，他们只需检查 差异；真的，我不是在开玩笑！] 这会导致很多不一致 在理智的情况下 库/模块/功能和 花费太多精力去纠正 在这些过程中由于回归而产生的缺陷 合并。
现在的问题是：
有什么替代源代码控制系统 可以带来一些积极的改变 改善生活 程序员/经理和其他人 环境中？
由于周围的每个人似乎都喝了 KoolAid（并到处唱着“这就是事情是如何完成的”），甚至没有考虑寻找替代方案，所以现在是有人这样做的时候了。但考虑到使用该系统的人员类型，应牢记以下几个方面。
- 使用简单&&明白了，即使是 Joe Coder 也应该能够毫不费力地使用它。 （无论如何，这是不需要的，因为包装器会对人们隐藏真正的幕后内容）
- 巨大代码库（由跨多种语言的源代码组成），有多个（大约 30 个）活跃代码任何给定时间的分支。
- 轻松合并到各个分支。 （考虑到变化量相当大）
- 如果有的话，对该系统的商业支持将是很好的。
- 开发发生在 UNIX 服务器上（至少应该在 HP-UX/Solaris 上运行）
- 应该能够很好地扩展（数千个用户/数十万个源）
- 良好的文档
- 基于简单/清晰的浏览器界面来比较/查看更改/副本。
- 存储库中没有二进制文件，因此不必担心它们。
- 用于将当前存储库内容导入新系统的规定。
所以，请建议。有没有希望&&有出路吗？ :) 我很确定像 git 这样的东西会被彻底拒绝（他们相信“git 只适合聪明人”）
编辑：我也想到了 Mercurial 和 BitKeeper，并且已经向人们提到过它链。希望一切顺利！ 谢谢！ :)
Problem:
A huge code base spanning to several
million SLoC,
maintained(support/active enhancements
etc) by a horde of second/third rate
programmers(most of them who do not
really care). Decades ago, few smart
guys had put in place a wrapper that
uses CVS underneath and this system is
being used by current generation of
developers (90% of them have not used
CVS directly, or heard of/used another
command line source control system).
Effect:
Usage of CVS and multiple teams
working across multiple modules,
inevitably => CVS branch merges to
trunk. This would be an activity
practised in the most religiously and
ritualistically possible way. [=>
brute force; planned weeks ahead,
involving a dozen guys for 2/4 days. Hundreds(sometimes thousands) of sources handled, manually.
Funny part is, the people involved are not the original owners of the
fix, and they simply go by checking
the diffs; really, am not kidding!]
This leads to a lot of inconsistency
in the sanity of the
libraries/modules/functionality and
too much of effort is spent to correct
defects due to regression during these
merges.
And now, the question:
What alternative source control system
can bring in some positive change and
improve the lives of
programmers/managers and everyone else
in the environment?
Since everyone around there seems to have drunk the KoolAid (and sing "This-is-how-things-are-done-everywhere") without even giving a thought about finding an alternative, it is high time someone does that. But considering the sort of people who would use the system, the following aspects are to be kept in mind.
- Simple to use && understand, even Joe Coder should be able to use it without fuss. (Anyway this won't be needed, as the wrapper would hide real under-the-hood stuff from folks)
- A HUGE codebase (consisting of sources across multiple languages), with multiple(around 30) active branches at any given time.
- Easy merges to various branches. (considering that volume of changes is quite huge)
- Commercial support for the system would be sweet, if available.
- Development happens on UNIX servers (Should run on HP-UX/Solaris at least)
- Should scale well (thousands of users/hundreds of thousands of sources)
- Good Documentation
- Simple/lucid browser based interface to compare/view changes/copies.
- There are no binary files in repository, so need not bother about them.
- Provision for importing current repository contents into the new system.
So, please suggest. Is there hope && a way out? :) Am pretty sure stuff like git would be rejected outright (they believe "git is only for smart folks")
EDIT: I too have Mercurial and BitKeeper in mind, and have mentioned it to folks up the chain. Hoping for the best!
Thanks! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可能听说过“好、快、便宜”这句老话。这同样适用于这里。丰富的功能集带来了一定程度的复杂性。我认为如果不选择涉及一定复杂性的工具，您就无法满足该要求列表。我祝你尝试成功，但如果是我，我会选择一个好的工具并投入一些时间来培训用户。
You may have heard the old saying about good, fast and cheap. The same applies here. With a rich feature set come some degree of complexity. I don't believe that you can fulfill that list of requirements without picking a tool that is going to involve some complexity. I wish you luck in trying, but if it were me I would pick a good tool and invest some time into training the users.
如果这纯粹是“感知”问题 - 他们“认为”git 太复杂，请尝试建议 Mercurial 或 Bazaar - 他们可能对它们不够熟悉，从而形成了不准确的先入之见。
If it's purely a matter of "perception" - that they "perceive" git to be too complex, try suggesting Mercurial or Bazaar - they might not be familiar enough with them to have formed an inaccurate preconception.
Mercurial 是我的建议。为了避免“复杂”的感觉，请看一下
此网站。
它是“Joel Spolsky 对 Mercurial DVCS 的友好介绍”，为用户提供了一个优秀的教程（以及颠覆恢复部分），引导他们逐步完成编辑、提交、合并等。
Mercurial would be my suggestion. To avoid the "complexity," perception, take a look at
this site.
It is "A friendly introduction to the Mercurial DVCS by Joel Spolsky," and it provides an excellent tutorial for users (and a subversion recovery portion) which takes them through step by step editing, committing, merging, etc.
我将放弃转向 Subversion 的建议。它不是所有酷孩子都使用的性感的分布式源代码控制，但是，这就是我建议它的原因，SVN 应该是从 CVS 的轻松迁移。它已经成熟、使用良好，并且在某些方面与 CVS 概念相似。 （现在，如果您的开发人员甚至远离这一点，那可能也无济于事。）
很多很多人都完成了这种迁移。有实用程序可以将您的代码从CVS迁移到SVN（但并非没有一些痛苦）。
它应该可以满足您的大部分要求（尽管合并的容易程度值得商榷）。
底线是：您的挑战不是技术。这就是领养。如果你的团队不想改变，那就不会改变。可悲的是，任何解决方案都注定会失败。你必须让他们相信他们首先需要改变。最好的选择是迎合他们的懒惰（我的意思是以积极的方式），并表明如果他们改变，“生活会更好”。
I'll throw out the suggestion of moving to Subversion. It's not the sexy distributed source control that all the cool kids are using, but, and this is the reason I am suggesting it, SVN should be an easy migration from CVS. It's established, well-used, and conceptually similar to CVS in some respects. (Now, if your developers are so far removed from even that, it might not help.)
Many, many people have done this migration. There are utilities out there to migrate your code from CVS to SVN (but not without some pain).
It should address most of your requirements (though how easy merging can be is debatable).
Bottom line is: your challenge isn't the technology. It's the adoption. If your team doesn't want to change, it won't. And sadly, any solution will be doomed. You have to convince them they need a change first. The best bet is to appeal to their laziness (I mean that in a positive way) and show that "life will be better" if they change.
任何工具都需要培训。我想说，如果你有信心会转向其他系统，那么花一些时间来培训这些人是完全有意义的，这样从长远来看，这将非常有帮助。
通过查看您的需求集，我建议尝试查看 svn 或 sos。拥有 sos 的优点是您可以获得 24*7 的问题支持。他们可以处理大数据。他们还有一个很酷的浏览器界面。
Any tool would need training. I would say that if you are confident that you will be moving to some other system then it makes complete sense to spend sometime on training the guys so that in the longer run it would be very helpful.
By looking at your requirement set I'd say try looking at svn or sos. Advantage of having sos is that you get 24*7 support on issues. They can handle large data. They also have a cool browser interface.