duk*_*ing 5 mercurial git perforce
我在一家大型跨国公司担任软件工程师，目前我正在与 IT 和其他开发人员就采用 DVCS（Mercurial 和/或 Git）进行非常愉快的对话。
IT 提出的问题之一是合规性和知识产权（顺便说一句，Perforce 大声谈论了这一点以及与 Git 相关的问题）。在我看来，IT 的印象是因为 Mercurial/Git 是分布式的，所以在每台开发人员机器上都有存储库是一种失控的情况，他们必须审核每个存储库。
我认为 IT 部门担心的另一件事是现在拥有“100”个存储库而不是“10”个庞大的存储库，我的印象是他们认为维护/监控它们的管理工作会增加“10-折叠”。我认为存储库管理软件（Rhodecode、Atlassian Stash）将是实现访问控制和可追溯性的第一步。
我的问题是：
存储库管理软件是否足以满足这种规模的公司（比方说约 2000 名开发人员和约 10 个服务器上的约 50 个 Perforce 仓库）是否合规（并满足其他企业要求？）
这个“合规性”要求到底包含什么？，您是否可以提供任何参考资料（例如 IEEE 标准或类似标准）？
我的公司已经使用 Perforce 大约 10 年了
当您切换到 DVCS 时，并没有太大的变化。最大的区别在于，每个开发人员工作站上的源代码副本现在也是其自己的存储库。
我怀疑 IT 部门有充分理由担心这一点。仅仅因为 git 和 Mercurial 是分布式的，并不意味着您将直接从某些开发人员的桌面进行部署/交付。仍然有可能 - 并且几乎肯定有必要 - 继续使用每个人都签入的一些中央存储库，以进行测试、质量检查和最终发布。
无论 IT 部门是否监控开发人员工作站上的源代码，都不会发生任何真正的变化。一旦推送到中央存储库，您仍然会将更改历史记录放入中央存储库中，我怀疑这是他们真正关心的。
从 IT 的角度来看，您从中获得的好处是，每当开发人员进行提交时，您就不会每隔几分钟（或几秒钟！）就访问中央存储库。开发人员可以完成某项工作，然后仅在准备就绪时才将其推送，但仍然可以在其工作站上进行完整的版本控制，而无需频繁访问网络。
最后，您需要与 IT 部门进行更详细的交谈，了解他们所讨论的合规性问题的确切性质。这可以是管理知识产权、ISO 9000 或某些政府法律/法规的任何内容。
（致所有人：请随意改进这个答案；这不是我的专业领域......）
| 归档时间： |
|
| 查看次数： |
122 次 |
| 最近记录： |