Один репозиторий 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 начал взимать плату за репо.

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

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

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

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

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

Это не двоичная, черно-белая проблема.

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

JFTR:

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

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

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

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

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

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

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

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

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

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

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

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

Имейте в виду, что при принятии решения многие репозитории 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

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

Мы небольшая софтверная компания и используем единое репо для всех наших разработок. Дерево выглядит так:

/client/<clientname>/<project>/<trunk, branches, tags>

Идея заключалась в том, что в одном репо у нас будет клиентская и внутренняя работа, но в итоге наша компания стала «клиентом» самой себя.

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

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

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

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

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

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

Подобно предложению Blade об обмене файлами, это немного более простое, но менее гибкое решение. Наш настраиваю так:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

В «bin» я храню сценарий под названием svn-create.sh, который выполнит всю настройку по созданию пустого репозитория. Я тоже храню там сценарий резервного копирования.

В "repository_files" я храню общие каталоги "conf" и "hooks", на которые все репозитории имеют символьные ссылки. Тогда есть только один набор файлов. Тем не менее, это исключает возможность получения детального доступа к каждому проекту без разрыва ссылок. Я не беспокоился об этом.

Наконец, я держу основной каталог / var / svn под контролем источника, игнорируя все, что есть в svnroot. Таким образом, файлы и скрипты репозитория также находятся под контролем источника.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Подобно 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 в этой структуре папок; а теги branch | могут быть полезны для пометки настроек для разных основных версии продуктов вендора тоже).

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

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

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