dvcs - PlasticSCM 存储库的权限如何在 DVCS 场景中工作

Question

所以我一直在做一个相当大的项目，并像 VCS 一样使用 PlasticSCM。我将它与 DVCS 模型一起使用，但到目前为止，我几乎只是在我的办公机器和家庭之间进行同步。

现在我们正在让其他人参与该项目，而我想做的是将其他开发人员限制在特定的分支中，以便只有 我 可以将分支合并到/main。

所以我去了我的本地存储库，并进行了权限更改(这部分非常简单)。但是现在它如何与其他开发人员一起工作？当他们同步时，权限是否复制到他们的本地存储库中？如果他们尝试合并到本地存储库上的/main 中，是否允许这样做，然后当他们尝试将更改推送到我的存储库时出现错误？

这是我第一次涉足 DVCS，所以我不太确定这种东西是如何工作的。

Answer 1

经典 DVCS(Mercurial、Git)不包含 ACL，这意味着克隆不会保留任何 ACL 限制。
这通常是通过原始 repo 上的钩子(Hook)来维护的(这意味着您可能能够在克隆的 repo 上修改错误的分支，但您将无法推回原始 repo)。

作为security page提到，这不是 PlasticSCM 的情况，克隆应该保留对象上设置的 ACL(下面的警告)，它将通过两个领域继承所述 ACL:文件系统层次结构(目录、子目录、文件)和存储库对象层次结构:



DVCS 设置中的警告是必须有一个机制来处理 。 translate users and groups from one site to another .

The Plastic replication system supports three different translation modes:

• Copy mode: it is the default behaviour. The security IDs are just copied between repositories on replication. It is only valid when the servers hosting the different repositories involved work in the same authentication mode.
• Name mode: translation between security identifiers is done based on name. In the sample at Figure above suppose user daniel has to be translated by name from repA to repB. At repB the Plastic server will try to locate a user with name daniel and will introduce its LDAP SID into the table if required.
• Translation table: it also performs a translation based on name, but driven by a table. The table, specified by the user, tells the destination server how to match names: it tells how a source user or group name has to be converted into a destination name. Figure below explains how a translation table is built and how it can translate between different authentication modes.

Note: a translation table is just a plain text file with two names per line separated by a semi-colon “;”. The first name indicates the user or group to be translated (source) and the one on the right the destination one.