所以我一直在做一个相当大的项目，并像 VCS 一样使用 PlasticSCM。我将它与 DVCS 模型一起使用，但到目前为止，我几乎只是在我的办公机器和家庭之间进行同步。
现在我们正在让其他人参与该项目，而我想做的是将其他开发人员限制在特定的分支中，这样只有我才能将分支合并到/main中。
所以我去了我的本地存储库，并进行了权限更改（这部分非常简单）。但是现在它如何与其他开发人员一起工作？当他们同步时，权限是否复制到他们的本地存储库中？如果他们尝试合并到本地存储库上的/main中，是否允许这样做，然后当他们尝试将更改推送到我的存储库时出现错误？
这是我第一次涉足 DVCS，所以我不太确定这种东西是如何工作的。
经典 DVCS（Mercurial、Git）不包含 ACL，这意味着克隆不会保留任何 ACL 限制。
这通常是通过原始 repo 上的钩子来维护的（这意味着您可能能够在克隆的 repo 上修改错误的分支，但您将无法推回原始 repo）。
正如安全页面所提到的，PlasticSCM 不是这种情况，克隆应该保留对象上设置的 ACL（下面的警告），它将通过两个领域继承所述 ACL：文件系统层次结构（目录、子目录、文件) 和存储库对象层次结构：
DVCS 设置中的警告是，必须有一种机制将用户和组从一个站点转换到另一个站点。
Plastic 复制系统支持三种不同的翻译模式：
- 复制模式：这是默认行为。安全 ID 只是在复制时在存储库之间复制。仅当托管所涉及的不同存储库的服务器以相同的身份验证模式工作时才有效。
- 名称模式：安全标识符之间的转换是基于名称完成的。在上图的示例中，假设用户
daniel必须按名称从 转换repA为repB。在repB塑料服务器将尝试找到具有名称的用户，daniel并在需要时将其LDAP SID引入表中。- 翻译表：它也执行基于名称的翻译，但由表驱动。由用户指定的表告诉目标服务器如何匹配名称：它告诉源用户或组名称必须如何转换为目标名称。下图说明了转换表是如何构建的，以及它如何在不同的身份验证模式之间进行转换。
注意：翻译表只是一个纯文本文件，每行有两个名称，用分号“<code>;”分隔。第一个名称表示要翻译的用户或组（源），右侧的名称表示目标用户或组。