Как работают разрешения для репозитория PlasticSCM в сценарии DVCS - PullRequest
Новая
       39

Как работают разрешения для репозитория PlasticSCM в сценарии DVCS

4 голосов
/ 01 февраля 2012

Так что я работаю над довольно крупным проектом и использую PlasticSCM, как от VCS.Я использую его с моделью DVCS, но пока я просто синхронизировал мой офисный компьютер с домом.

Теперь мы привлекаем к проекту других людей и то, что я хотел бынужно ограничить других разработчиков определенными ветками, чтобы только I мог объединять ветви в / main .

Так что я пошел в свой локальный репозиторий и сделализменения разрешений (эта часть довольно проста).Но как это работает с другими разработчиками?Когда они синхронизируются, реплицируются ли разрешения в их локальных репозиториях?Если они попытались слиться с / main в своем локальном репозитории, разрешит ли это это, и тогда они получат ошибку, когда попытаются отправить изменения в мой репозиторий?

Это мойпервый набег в DVCS, так что я не совсем уверен, как это работает.

1 Ответ

3 голосов
/ 01 февраля 2012

Классический DVCS (Mercurial, Git) не включает ACL, что означает, что клон не будет соблюдать никаких ограничений ACL.
Обычно это поддерживается через ловушку в исходном репо (это означает, что вы можете изменить неправильную ветку в клонированном репо, но не сможете вернуться к исходному репо).

Как упоминает страница безопасности , это не относится к PlasticSCM, и клон должен сохранить ACL (пояснение ниже), установленный для объекта, который унаследует указанный ACL через две области: иерархия файловой системы (каталог, подкаталоги, файлы) и иерархия объектов репозитория:

ACL inheritance

Предостережение в настройках DVCS заключается в том, что должен существовать механизм для перевода пользователей и групп с одного сайта на другой .

translation example

Система репликации из пластика поддерживает три различных режима перевода:

  • Режим копирования: это поведение по умолчанию. Идентификаторы безопасности просто копируются между репозиториями при репликации. Он действителен только в том случае, если серверы, на которых размещены различные репозитории, работают в одном и том же режиме аутентификации.
  • Режим имени: перевод между идентификаторами безопасности выполняется на основе имени. В примере на рисунке выше предположим, что пользователь daniel должен быть переведен по имени с repA на repB. На repB сервер Plastic попытается найти пользователя с именем daniel и в случае необходимости введет его LDAP SID в таблицу.
  • Таблица перевода: она также выполняет перевод на основе имени, но управляется таблицей. Таблица, указанная пользователем, сообщает целевому серверу, как сопоставлять имена: она сообщает, как исходное имя пользователя или группы должно быть преобразовано в целевое имя. На рисунке ниже показано, как создается таблица перевода и как она может переводиться между различными режимами аутентификации.

translation table

Примечание: таблица перевода - это просто текстовый файл с двумя именами в строке, разделенными точкой с запятой «;». Первое имя указывает на пользователя или группу для перевода (источник), а имя справа - на целевое.

...