Проблема с подрывной деятельностью, проверкой и ограничениями

#svn

#svn

Вопрос:

Если у меня есть репозиторий, скажем repo1 , со 100 папками в нем, и я хочу, чтобы пользователь, который проверяет это, имел доступ только, скажем, к двум папкам, dir1 и dir2 .

Как это можно сделать, используя where я просто извлекаю repo1 папку. svn co svn://repo1 dest

Кажется, я не могу найти эффективный способ ограничить доступ к другим 98 папкам без индивидуальной записи строки ограничения в моем authz файле.

Если у меня есть

 [/]
user = 

[/repo1/dir1]
user = rw

[/repo1/dir2]
user = rw
  

Затем я не могу извлечь repo1 папку, так как у меня нет к ней доступа. Но чтобы иметь к нему доступ, все папки будут наследовать доступ.

Любая помощь будет оценена!!

Комментарии:

1. К вашему сведению, вы использовали неправильный синтаксис для path: часть репозитория должна быть определена по-другому [repo1:/dir1]

Ответ №1:

Попробуйте что-то вроде:

 [groups]
dev = Fred, Bill, Sue

[/]
* = r
@dev = rw

[/repo1/]
user = r

[/repo1/dir2]
user = rw

[/repo1/dir12]
user = rw

[/repo1/dir72]
user = rw
  

Это говорит о том, что по умолчанию у всех есть доступ на чтение, у группы разработчиков везде есть режим чтения-записи, а у «пользователя» есть rw только по трем определенным путям.

Обратите внимание, что разрешения применяются вниз, и по умолчанию никто нигде не имеет никаких разрешений. Более подробную информацию можно найти здесь.

В целом стратегия заключается в:

  • Установите значение по умолчанию для всего репозитория таким, какое должно быть у большинства пользователей.
  • Структурируйте свой репозиторий так, чтобы логически отражать группировки проектов обычно это также логически группирует разрешения пользователя.
  • Рассмотрим группировки пользователей и ролей.
  • Имейте в виду, что разрешения просачиваются вниз

Поэтому вместо:

 top-level-
  - Hundreds of directories
  

с сотнями пользовательских разрешений попробуйте структурировать вещи, похожие:

 top-level
  - Common Utilities
     - Command Line Utilities
     - GUI Utilities
     - Web Utilities
  - Database Stuff
  - Hardware Projects
     - HW_1
     - HW_2
  - Customer Projects
     - Retail Customers
        - Customer A
        - Customer B
     - Wholesale Customers
etc.
  

Тогда у вас может быть группа пользователей, которые являются сопровождающими для всех утилит, другая для всех клиентов, одна для баз данных и т. Д. (Имея в виду, что один пользователь может быть членом более чем одной группы. Они получат разрешения, установленные как группа, для всего в области и по умолчанию ниже (вложенные внутри), и вам нужно будет только установить разрешения для отдельных групп, которые являются особыми, т. Е. Должны обрабатываться только определенными людьми.

Также имейте в виду, что SVN — это система контроля версий, пока вы не предоставляете права администратора, вы всегда можете отменить, отменить, отменить плохие изменения. Если у вас есть люди, которым настолько нельзя доверять, что вы не должны их ни во что посвящать, потому что они могут нанести слишком большой ущерб, правильный ответ — обучить их, перевести их на роль, где они не могут нанести никакого ущерба или уволить их.

Комментарии:

1. Проблема в том, что все остальные папки «98» имеют доступ на чтение, когда я хочу, чтобы у них не было доступа. Это возможное решение, но, безусловно, последнее средство

2. @AllanMacmillan — вы должны явно написать правила запрета доступа для каждой вложенной в папку репозитория

3. @LazyBadger, значит, у меня должен быть огромный список [/repo1/dirX] user = ?

4. @AllanMacmillan — да :- (

5. Ваш ответ настолько правильный, насколько это возможно. Я работаю с файловой системой, которая генерирует веб-сайт нашей компании, и поэтому перенос каталогов невозможен. У нас уже так много поддиров, что 100 на самом деле довольно мало. Нам нужен доступ к родительской папке с таблицами стилей и скриптами, чтобы все остальные папки тоже имели к ней доступ. В любом случае спасибо