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

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

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

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

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

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


permissions svn externals
person HUAGHAGUAH    schedule 25.03.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

person nickf    schedule 25.03.2009

arrow_upward
2
arrow_downward

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

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

Что-то типа:

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

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

person Jim T    schedule 26.03.2009

arrow_upward
0
arrow_downward

Я знаю, что это старый поток, но у меня была проблема с внешними данными из 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>
person Floris Groenendijk    schedule 31.05.2018