2010-09-21 2 views
1

У нас есть репозиторий subversion с проектами верхнего уровня, каждый из которых имеет соединительные линии/ветки/теги. И теперь нам нужно ограничить доступ к одному из проектов для ограниченного числа разработчиков. Все работает нормально, за исключением того, что, хотя человек, который не имеет доступа к этому проекту, выполняет «обновление» в репозитории через TortoiseSVN, красное 403 «запрещенное» сообщение показано ему для проекта, который ему запрещено видеть. Это логично, но красные строки ошибок для sucessfull команд не очень хороши в целом: разработчики, которые всегда видят красные сообщения об ошибках durng update, вскоре привыкнут к ним и могут игнорировать сообщение об ошибке, которое является реальной ошибкой, а не информацией о разрешениях :(Итак, можно ли настроить сервер TortoiseSVN/VisualSVN, чтобы разработчики, у которых нет разрешений для некоторых проектов, не получат сообщения об ошибках для «обновления» команды? Таргетинг на репозиторий root?TortoiseSVN: можно ли игнорировать запрещенные папки во время обновления?

ответ

3

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

Это также гарантирует, что когда кто-то создает ветку (дешевая операция), она не заселена в wo копирование (дорогая операция).

Кроме того, поскольку операция блокировки работает в Subversion, операция блокировки займет больше времени и больше, если к рабочей копии добавлено больше каталогов. (Это изменится с версии 1.7)

Обратите внимание, что это также можно использовать sparse checkouts

+0

Возможно, я высказался неправильно. Например, у меня есть проект A, который проверяется как co svn: // myserver/svn/A/trunk C: \ A и у меня есть проект B, который выставляется как co svn: // myserver/svn/B/trunk C: \ B. Теперь, если пользователь, имеющий права доступа к A и не имеющие прав доступа для B, обновит svn: // myserver/svn, он получит красное сообщение об ошибке, поскольку «доступ к B запрещен». Это логично, но красные сообщения в каждом обновлении не очень хорошие :( – grigoryvp

+0

он не может обновить корень репозитория, хотя вы можете обновлять только рабочие копии. –

0

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

+0

Это хорошее решение, но ограниченные проекты зависят от многих вещей в текущий единый репозиторий: общий, libs и т. д.:. Будет очень сложно правильно создать два репозитория. – grigoryvp

Смежные вопросы