Дифференцированные права доступа в распределенных VCS

Question

В настоящее время я собрал большую часть своей работы в одном и хорошо организованном репозитории в Subversion.
Когда другому человеку, скажем X, необходимо сотрудничать в подпроекте, скажем /path/to/my/subproject, я могу простодать разрешения X на чтение / запись по этому конкретному пути.
С моей точки зрения, у меня все еще есть хорошо структурированное хранилище, и мне не нужно ничего делать, кроме как изменить некоторые простые разрешения, чтобы все работало на X - ис точки зрения Х, он имеет только доступ к соответствующей части.Все счастливы.

В распределенной VCS, такой как git или Mercurial, однако, кажется, что весь доступ предоставляется для репозитория.
Поэтому я не вижу, как получить функциональность, аналогичную описанной выше в этих системах.Кажется, мне нужно создать совершенно новый репозиторий, если человеку X внезапно понадобится доступ к частям моего исходного репозитория.
Кроме того, если другому человеку, скажем Y, нужны другие права доступа в пределах пути, к которому у X есть доступ, яесть проблема.

Могу ли я получить аналогичные функциональные возможности с дифференцированными правами доступа в распределенных VCS, как в настоящее время в Subversion?Если да, то как?

Answer 1

Еще один вариант - добавить слой авторизации , например Gitolite .

Он имеет настройки для авторизации пользователя:

• внести свой вклад в определенные ветви репозитория Git.
• и / или определить личные ветки .

Но в более общем смысле, да, один проект часто приравнивается к одному репо, чтобы этот "компонент" ("согласованный набор файлов") развивался самостоятельно, независимо от других.
Затем вы можете присоединиться к этим репо в пределах одного родительского репо через субмодули .

Отсутствие аутентификации и авторизации объясняется в « Распределенные системы контроля версий и предприятие - хорошее сочетание? ».

Answer 2

Это невозможно в git или любых других известных мне DVCS. Идея DVCS - децентрализовать все. Это связано с тем фактом, что хранилище не имеет центральной аутентификации. Если Джо клонирует ваше репо, он имеет полный доступ ко всему репо. Теперь вы можете ограничить то, что вы тянете в свой репозиторий, но он может делать с ним все, что пожелает.

Существуют сторонние решения, такие как Gitolite, которые позволят вам приблизить к желаемому поведению, но для этого потребуется настроить сервер и отслеживать ключи. Что может стоить

Ключевым моментом является то, что, , насколько я знаю , нет способа ограничить доступ для чтения к подкаталогу хранилища. Записью можно заниматься в Gitolite или выборочно делать git fetch, но после того, как пользователь клонировал репозиторий git, он полностью контролирует весь репозиторий , пока он находится на их компьютере.

Из руководства Gitolite:

• Доступ на чтение контролируется на уровне репо
• доступ для записи контролируется на уровне ветви / тега / файла / каталога, включая информацию о том, кто может перематывать, создавать и удалять ветви / теги