Структура хранилища с черепахой SVN Вопрос

Question

Большинство людей структурируют свои репозитории так, что является наилучшей практикой

MainRepository
    Project1
       branches
       trunk
       tags
    Project2
       branches
       trunk
       tags
..and so on

возникнет ли необходимость в создании второго репозитория?Я думаю, что большинство людей жили только с одним в качестве лучшей практики и никогда не должны были бы создавать вторую, верно?Или есть какие-то обстоятельства, когда вы можете захотеть создать более одного?

Answer 1

Я верю в создание нескольких репозиториев, каждый из которых содержит много связанных проектов.

Answer 2

Я за один репозиторий для каждого типа данных. Таким образом, все исходные коды и библиотеки поставщиков будут помещены в один репозиторий, другой репозиторий для результатов сборки и выпусков. Еще один репозиторий для развертывания библиотек. Еще один репозиторий для документов компании и т. Д.

В основном, отдельные репозитории, когда меняются правила использования репозитория. Это позволяет вам быть гибким с макетами, хуками, авторизацией и т. Д.

Например, вы хотите, чтобы документация вашей команды по продажам находилась под контролем исходного кода? Прекрасная идея, но вам, вероятно, не нужны ствол / теги / ветви, и пользователи, которые обращаются к нему, очень разные. Структура была бы совершенно иной, поэтому внезапно даже не имеет смысла пытаться связать ее с хранилищем исходного кода.

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

Answer 3

Создание отдельных репозиториев для каждого проекта полезно для управления временем жизни репозиториев. С новой версией 1.6 Subversion вы можете "упаковать svnadmin" в репозиторий для оптимизированного доступа. Кроме того, перемещать репозитории между серверами проще, когда у вас есть гранулярность.

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

Answer 4

Мы держим наши проекты совершенно отдельно. Приятно иметь один номер ревизии для распределения по нескольким смежным проектам, но, как бывший ИТ-менеджер, я слишком параноидален по поводу коррупции и сбоев, чтобы собрать все в одну «корзину».

Answer 5

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

При этом я считаю, что группа должна управлять своим собственным хранилищем, и это не должно быть на уровне предприятия.

Answer 6

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