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

Question

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

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

Answer 1

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

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

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

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

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

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

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

JFTR:

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

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

---

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

Answer 10

Аналогично предложению Blade об обмене файлами, здесь есть несколько более простое, но менее гибкое решение. Я настраиваю наши так:

• / вар / SVN /
• / вар / СВН / бен
• / вар / SVN / repository_files
• / вар / СВН / svnroot
• / вар / SVN / svnroot / repos1
• / вар / SVN / svnroot / repos2
• ...

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

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

Наконец, я держу основной каталог / 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)"