OS项目的mercurial和企业项目的svn？

Question

如果我错了，请更正我，但不是为OS项目分发SCM，而集中式SCM更适合公司/私人项目？

因为例如。 mercurial任何人都可以获得具有完整历史记录功能的存储库的精确副本，而在集中式的情况下，您只能获得最新的工作副本。

我更关注私人项目，所以我想知道集中式SCM是否更好或不重要？

Answer 1

你可以use a DVCS (like mercurial) in large corporation。

与VCS相比，DVCS的限制基本上是：

• size （您无法无限期地将所有内容存储在DVCS中，这意味着您应该重新考虑仍可在大型项目中找到的开发数据as modules instead of a monolithic set of files）
• 正确的访问管理：它在DVCS中并不像在VCS中那样精细，主要是因为许多外部参与者可以使用不同的用户身份验证方案为项目做出贡献。 ownership管理起来比较棘手。
• 工作流程：DVCS工作流程更加复杂，即使它可以emulate the one of a CVCS（一个中央回购作为所有其他人的参考）

那就是DVCS allows for a new way to publish（拉/拉）数据，这可以帮助团队之间的“预交付”（当团队想要分享开发时，即使仍在进行中并且尚未正式承诺到中央存储库）：你变成了passive produced and an active consumer。

---

Tomislav Nakic-Alfirevic在评论中提出：

  

您能否说明您将DVC与集中式DVC进行比较的第二点？

正确的访问管理很棘手，特别是如果大公司：

• 必须与外部企业共享其部分存储库以进行共享外包开发
• 允许将其部分存储库克隆到个人计算机上（当在不同站点的移动环境中工作时，开发人员不会始终访问企业网络）。

在这些情况下，这意味着：

• 用户身份验证并不总是很容易协调（同一个用户可以根据他/她克隆存储库的位置具有不同的身份）。可以设置基于SSH的身份验证（gitosis，gitauth）。
• 与文件关联的元数据受限于Git tags for instance
  （例如，在克隆repo的给定计算机上，文件组可能不存在） （来自other tools are not transparently supported的元数据）
  （special characters in filenames can be problematic）
• 访问权限通常仅限于所有存储库，而不是每个分支或每个文件本地管理（必须为Git配置像gitolite这样的服务器，而不是总是有一个服务器的CVS，意味着将更多地包含在内以提出更精细的ACL）

Git，例如is a bit too simple直接回答大公司的关注：

  

git的新手（意思是，当我开始时我建议使用这样的增强功能;））经常谈论添加此功能或该功能，而没有意识到git真的非常简单。
  它有文件，目录，提交，标签和就是它   它集中解决方案的优势在于代理标识符的缺乏，例如a   分支路径，服务器分配的序列号等。

     

是的，可能会有更多的关系和元数据来代表很多东西   每个文件的历史记录和合并，目录重命名，樱桃采摘，还原   但这些都增加了基本模型的复杂性，基本模型已经证明自己有能力处理这些事情 - 需要注意   但是，回报 - 简单 - 非常值得注意。

Answer 2

不，绝对不是。 DVCSes不适合企业的这一建议是有针对性的错误，是一种普遍的FUD论证，无论出于何种原因，他们不希望放弃SVN。

实际上，在企业设置中，DVCS也会带来很多好处：

• 能够经常办理登机手续而不会有阻挡其他人的风险
• 离线工作
• 高性能
• 有效分支/合并
• 拉出访问模式

关于最后一个，您可以给经验丰富的开发人员直接推送访问主存储库，而对于新成员或初级成员，他们的导师会从他们那里获取并在推送之前查看他们的更改。

参与上述答案中的讨论;通过这种方式，DVCSes可以为您的存储库提供更多控制权，而对于SVN，通常唯一真正可行的模型是让所有贡献者提交对至少部分代码的访问权。

对于包含代码的部分，您可能对权限的细粒度控制较少，但是您可以为不同的组（例如文档团队）提供他们自己的主存储库克隆，并在审核后定期将其合并。或者将文档放在完全不同的存储库中。

通常，您需要取消学习使用集中式VCS学习的实践，回到用例以及您想要做的事情，然后考虑DVCS如何赋予它权力。

要了解版本控制系统之间差异的一篇非常好的文章是Making Sense of Revision-Control Systems。