Один репозиторий SVN или много?

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

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

или вы бы создали новые репозитории для каждого из них?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

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

Причина, по которой я спрашиваю, заключается в том, что я собираюсь объединить несколько репо в одно, поскольку мой хост SVN начал взимать плату за репо.

svn
103 голоса | спросил nickf 31 +03002008-10-31T05:34:03+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:34:03 +0300 2008, 05:34:03

11 ответов


0

Проблема «один против нескольких» сводится к личным или организационным предпочтениям.

Управление множеством против одного в основном сводится к контролю и обслуживанию доступа.

Контроль доступа для одного репозитория может содержаться в одном файле; Для нескольких репозиториев может потребоваться несколько файлов. У обслуживания есть похожие проблемы - одна большая резервная копия или много маленьких резервных копий.

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

Недавно я консультировался с относительно крупной фирмой по миграции нескольких систем управления исходным кодом на Subversion. У них около 50 проектов, от очень маленьких до корпоративных приложений и их корпоративного веб-сайта. Их план? Начните с одного репозитория, при необходимости перенесите его в несколько. Миграция почти завершена, и они все еще находятся в одном репозитории, никаких жалоб или проблем не поступало, так как это единственный репозиторий.

Это не двоичный файл, черный & белый вопрос.

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

JFTR:

номера ревизий в Subversion действительно не имеют никакого значения вне репозитория. Если вам нужны значимые имена для ревизии, создайте TAG

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


Изменить. См. ответ Blade об использовании единой конфигурации авторизации /аутентификации для SVN.

ответил Ken Gentle 31 +03002008-10-31T05:57:07+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:57:07 +0300 2008, 05:57:07
0

Для вашего конкретного случая идеально подходит один (1) репозиторий. Вы сэкономите много денег. Я всегда призываю людей использовать один репозиторий. Потому что это похоже на одну файловую систему: Это проще

  • У вас будет единственное место, где вы будете искать код
  • У вас будет одно разрешение
  • У вас будет один номер коммита (когда-либо пытались создать проект, который распространяется на 3 репозитория?)
  • Вы можете лучше использовать общие библиотеки и отслеживать свои успехи в этих библиотеках (svn: externals - это PITA и не решит все проблемы)
  • Проекты, запланированные как полностью разные элементы, могут объединяться и совместно использовать функции и интерфейсы. Это будет очень трудно достичь в нескольких репо.

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

SVN очень хорошо масштабируется с большими репозиториями, нет замедления даже на больших (> 100 ГБ) репозиториях.

Таким образом, у вас будет меньше хлопот с одним хранилищем. Но вы действительно должны подумать о макете репо!

ответил Peter Parker 31 +03002008-10-31T06:48:51+03:00312008bEurope/MoscowFri, 31 Oct 2008 06:48:51 +0300 2008, 06:48:51
0

Я бы использовал несколько репозиториев. Помимо проблемы с доступом пользователей, это также упрощает резервное копирование и восстановление. И если вы окажетесь в ситуации, когда кто-то хочет заплатить вам за ваш код (и его историю), проще дать им просто дамп хранилища.

Я бы предположил, что консолидация репозиториев только из-за политики тарификации вашего хостинг-провайдера не очень хорошая причина.

ответил Greg Hewgill 31 +03002008-10-31T05:39:21+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:39:21 +0300 2008, 05:39:21
0

Мы используем один репозиторий. Моей единственной заботой было масштабирование, но после просмотра хранилища ASF (700 тыс. Ревизий и подсчет) я был довольно убежден производительность не будет проблемой.

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

ответил Mark Renouf 31 +03002008-10-31T06:51:55+03:00312008bEurope/MoscowFri, 31 Oct 2008 06:51:55 +0300 2008, 06:51:55
0

Помните, что при принятии решения многие репозитории SVN могут использовать один и тот же файл конфигурации.

Пример (взято из ссылки выше):

В оболочке:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Файл: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Файл: /var /svn /conf /authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw
ответил Frederic Morin 31 +03002008-10-31T09:05:38+03:00312008bEurope/MoscowFri, 31 Oct 2008 09:05:38 +0300 2008, 09:05:38
0

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

ответил CMS 31 +03002008-10-31T05:44:13+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:44:13 +0300 2008, 05:44:13
0

Лично я бы создал новые репозитории для каждого. Это значительно упрощает процесс проверки и упрощает администрирование, по крайней мере, в отношении доступа пользователей и резервного копирования. Кроме того, это позволяет избежать проблемы глобального номера версии, поэтому номер версии имеет смысл во всех проектах.

На самом деле, вы должны просто использовать git;)

ответил Paul Wicks 31 +03002008-10-31T05:43:05+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:43:05 +0300 2008, 05:43:05
0

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

Я использую TortuiseSvn и обнаружил, что опция «Показать журнал» является обязательным инструментом. хотя ваши проекты не связаны, я уверен, что вы обнаружите, что централизованная глобальная межпроектная информация (пути, идентификаторы ошибок, сообщения и т. д.) всегда полезна.

ответил ofer 10 ThuEurope/Moscow2009-12-10T00:58:14+03:00Europe/Moscow12bEurope/MoscowThu, 10 Dec 2009 00:58:14 +0300 2009, 00:58:14
0

Если вы планируете использовать такой инструмент, как trac, который интегрируется с SVN, или использовать его, имеет смысл использовать одно репо на проект.

ответил Frederic Morin 31 +03002008-10-31T07:20:08+03:00312008bEurope/MoscowFri, 31 Oct 2008 07:20:08 +0300 2008, 07:20:08
0

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

Но, опять же, даже это не очень хорошая причина использовать несколько.

ответил Levi Rosol 31 +03002008-10-31T05:36:36+03:00312008bEurope/MoscowFri, 31 Oct 2008 05:36:36 +0300 2008, 05:36:36
0

Подобно тому, как mlambie использует один репозиторий, но пошел немного дальше со структурой папок, чтобы легко масштабировать до определенного типа проектов - проекты на основе веб-html по сравнению с cs (C #) или с sql (сценарии создания /выполнения SQL) против .xyz (специфичные для домена языки, такие как afl (язык формулы AmiBroker) или ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Обратите внимание, у меня есть ствол, живущий в ветвях, поскольку я рассматриваю его как ветвь по умолчанию. Единственная боль иногда возникает, когда вы хотите быстро создать другой проект, вам нужно создать структуру ProjectName /branch | tags. Я использую настройки приложения просто как место для хранения определенных файлов настроек приложений в репозитории, чтобы их можно было легко обменивать с другими (и заменяю ClientName на VendorName и ProjectName на AppName в этой структуре папок; а теги | филиалов | могут быть полезны для пометки настроек в различных основных версии продуктов производителя тоже).

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

ответил J.D. 1 J0000006Europe/Moscow 2010, 20:02:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132