分布式版本控制系统和企业 - 一个很好的组合？

Question

我可以看到为什么分布式源代码控制系统（像Mercurial这样的DVCS）对开源项目有意义。

但它们对企业有意义吗？ （通过集中的源控制系统，如TFS）

DVCS的哪些功能使其更适合或更适合拥有众多开发人员的企业？ （通过集中式系统）

Answer 1

Answer 2

要添加其他评论，我会发现您没有理由不能拥有企业中央存储库。从技术上讲，它只是另一个存储库，但它是您生产的产品。我已经使用VCS的这种或那种形式超过30年了，我可以说切换到Mercurial就像一个城市男孩第一次呼吸清洁的乡村空气。

Answer 3

与离线或慢速网络的集中式系统相比，DSCS（通常）有更好的故事。它们往往更快，这对于进行大量签到的开发人员（使用TDD）来说是非常明显的。

集中式系统最初更容易掌握，对于经验不足的开发人员来说可能是更好的选择。 DVCS允许您创建大量的迷你分支并隔离新功能，同时仍然可以在绿色编码样式上执行red-gree-refactor checkin。同样，这是非常强大的，但只对相当精明的开发团队有吸引力。

如果你处理像数字资产和非文本文档（PDF和Word等）这样不可合并的文件，那么拥有一个支持独占锁的单一中央存储库是有意义的，因为它可以防止你陷入困境并手动合并

我认为开发人员或代码库大小的数量并不多，两个系统都显示支持大型源代码树和提交者数量。但是对于大型代码库和项目，DVCS在快速创建分散的远程分支方面提供了很大的灵活性。你可以用集中式系统来做到这一点，但你需要更加慎重，无论好坏。

简而言之，需要考虑一些技术方面，但您还应该考虑团队的成熟度以及他们围绕SCCS的当前流程。

Answer 4

至少在tfs 2013中，您可以与本地工作区断开连接。分布式与集中式是由业务定义的，取决于正在开发的项目的需求和要求。

对于企业项目，将工作流和文档连接到代码更改的能力对于将业务需求和更高阶元素连接到解决特定更改，错误或功能添加的特定代码更改至关重要。

工作流和代码存储库之间的这种连接将TFS与仅代码存储库解决方案分开。对于需要更高级别的项目审核的地方，只有像TFS这样的产品才能满足更多的项目审核要求。

可以在此处找到应用程序生命周期管理过程的概述。

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

Answer 5

我们在企业环境中面临的最大问题是缺乏基于路径的读访问控制。它是Git架构中固有的（我假设大多数DVCS），如果你有对存储库的读访问权，你就可以得到整个东西。但有时一个项目需要一个稀疏的结账（即您希望版本控制敏感数据靠近源，或者您希望给第三方选择性地查看项目的一部分）。

开箱即用，Git没有提供任何权限 - 你已经有了自己编写的钩子。

大多数流行的回购管理器GithubEnterprise，Gitlab，Bitbucket都提供基于分支的写入限制。 Gitolite允许更细粒度，提供基于路径（和更多）的写入限制。

我唯一听说过支持读访问的repo管理器是Perforce Helix，它在perforce后端重新实现了git协议，但我没有实际经验。这很有希望，但我会担心它与＃34;普通＆＃34; GIT中。

Answer 6

对我来说，他们提供的最大的东西是速度。对于最常见的操作，它们比集中式源控制快几个数量级。

断线连接也是一个巨大的优势。

Answer 7

绝对一个分布式源模型在企业中是有意义的，但它确实取决于团队的结构。

分布式源代码管理使您可以灵活地创建自己的工作流程。

想象一下，如果你愿意的话，一个更大的团队，其中有更小的团队在不同的功能分支上工作。

• 这些团队都可以拥有自己的中央存储库，并拥有自己的构建自动化/签入控制机制。
• 他们可以在任何地方工作，并随时备份他们的本地工作。
• 然后他们可以选择他们想要在群组之间分享的签到。
• 他们可以拥有一个单独的集成商，在他们自己的机器上工作，执行合并，而不会影响他人。

这些是您可以通过传统的集中式服务器实现的功能，但正如@Brook指出的那样，集中式模型必须扩展，而分布式模型已经分片，所以没有（或至少更少）需要垂直扩展任何服务器。

Answer 8

在切换到Mercurial之前，我们的团队使用TFS约3年。 HG的分支/合并支持比TFS好得多。这是因为DVCS依赖于无痛合并。

Answer 9

跨远程/断开连接的位置实现更好的同步。