SVN: внешние и разрешения - PullRequest
Новая
       16

SVN: внешние и разрешения

1 голос
/ 25 марта 2009

Я запускаю проект svn с дополнительными компонентами - извлечение из нескольких внешних репозиториев и нескольких пользователей с различными правами доступа к этим внешним файлам.

Команда 'svn update' прерывается при первом проекте, который она не может получить.

Существует ли лучшая или стандартная методология для svn: externals, чтобы обеспечить успешное извлечение денег для всех пользователей?

РЕДАКТИРОВАТЬ: У меня нет прав собственности / контроля над внешними проектами для предоставления доступа, и в соответствии с политикой компании не допускается зеркалирование внешних объектов. Поскольку внешние компоненты поддерживают дополнительные компоненты, пользователи с меньшими разрешениями, очевидно, не будут поддерживать дополнительные компоненты. Тем не менее, им все равно нужно будет проверить другие внешние объекты, и svn up очень зависит от порядка.

Я понимаю, что исправление разрешений и разбиение на под-репозитории сделают это не проблемой, но мне все еще интересно знать, есть ли какое-либо среднее положение.

Ответы [ 3 ]

3 голосов
/ 25 марта 2009

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

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

2 голосов
/ 26 марта 2009

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

Требуется много управления и мысли.

Что-то вроде: 

/Projects
 /Project1
  /trunk
 /Project2External
  /tag1
/Workspaces
 /Project1
  /DevA - svn:external Project1/trunk Project2/tag1
  /DevB - svn:external Project1/trunk

Но вы должны быть готовы реструктурировать проект таким образом и подумать о том, что делать, когда происходят глобальные изменения во внешнем. Но, таким образом, вы все равно будете работать над стволом проекта1, так что никаких дополнительных действий не возникает.

0 голосов
/ 31 мая 2018

Я знаю, что это старый поток, но у меня была проблема с внешними файлами из github с другим именем пользователя и паролем из хранилища svn Я не хочу потерять решение, поэтому для потомков, здесь я иду:)

Для обновления локальной проверки SVN: 

svn switch --username <username> --password <password> http://svn.server/svn/exampleProject --ignore-externals

Это не будет обновлять внешние данные!

Теперь, чтобы обновить внешние данные, используя другое имя пользователя и пароль: 

svn up <path_to_external> --username <external_username> --password <external_password>
...