Один репозиторий 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 начал взимать плату за репо.
13 ответов
Одиночная или множественная проблема сводится к личным или организационным предпочтениям.
Управление множеством против одного в основном сводится к контролю и обслуживанию доступа.
Контроль доступа для одного репозитория может содержаться в одном файле; Для нескольких репозиториев может потребоваться несколько файлов. У обслуживания есть похожие проблемы - одна большая резервная копия или много маленьких резервных копий.
Я управляю своим собственным. Есть один репозиторий, несколько проектов, каждый со своими тегами, стволом и ветвями. Если кто-то становится слишком большим или мне нужно физически изолировать код клиента для его удобства, я могу быстро и легко создать новый репозиторий.
Недавно я консультировался с относительно крупной фирмой по миграции нескольких систем управления исходным кодом на Subversion. У них около 50 проектов, от очень маленьких до корпоративных приложений и их корпоративного веб-сайта. Их план? Начните с одного репозитория, при необходимости перенесите его в несколько. Миграция почти завершена, и они все еще находятся в одном репозитории, никаких жалоб или проблем не поступало, так как это единственный репозиторий.
Это не бинарный, черно-белый вопрос.
Делайте то, что работает для вас - будь я на вашем месте, я бы объединял проекты в один репозиторий так быстро, как мог набирать команды, потому что стоимость была бы основным фактором в моей (очень, очень маленькой) компании.
JFTR:
номера ревизий в Subversion действительно не имеют никакого значения вне репозитория. Если вам нужны значимые имена для ревизии, создайте TAG
Сообщения коммитов легко фильтруются по пути в репозитории, поэтому чтение только тех, которые связаны с конкретным проектом, является тривиальным упражнением.
Изменить: см. Ответ Frederic Morin для получения подробной информации об использовании единой конфигурации авторизации / аутентификации для SVN.
Для вашего конкретного случая идеально подходит один (1) репозиторий. Вы сэкономите много денег. Я всегда призываю людей использовать один репозиторий. Потому что это похоже на одну файловую систему: это проще
- У вас будет единственное место, где вы будете искать код
- У вас будет одно разрешение
- У вас будет один номер коммита (когда-либо пытались создать проект, который распространяется на 3 репозитория?)
- Вы можете лучше использовать общие библиотеки и отслеживать ваши успехи в этих библиотеках (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 для взаимодействия с ним. Номера ревизий распространяются на весь репозиторий и не относятся только к одному проекту, но это не ставит нас в тупик.
Я бы создал отдельные репозитории... Почему? Номера ревизий и сообщения о коммитах просто не будут иметь никакого смысла, если у вас есть много не связанных между собой проектов в одном репозитории, это наверняка будет большой беспорядок в краткосрочной перспективе....
Еще одна важная вещь, которую следует учитывать, это тот факт, что использование нескольких репозиториев приводит к тому, что вы теряете возможность ведения единой регистрации (команда svn log), и это само по себе будет хорошей причиной для выбора одного репозитория.
Я использую TortuiseSvn и обнаружил, что опция "Показать журнал" является обязательным инструментом. хотя ваши проекты не связаны, я уверен, что вы обнаружите, что централизованная глобальная межпроектная информация (пути, идентификаторы ошибок, сообщения и т. д.) всегда полезна.
Лично я бы создал новые репозитории для каждого. Это значительно упрощает процесс проверки и упрощает администрирование, по крайней мере, в отношении доступа пользователей и резервного копирования. Кроме того, это позволяет избежать глобальной проблемы с номером версии, поэтому номер версии имеет смысл во всех проектах.
На самом деле, вы должны просто использовать git;)
Если вы планируете использовать такой инструмент, как trac, который интегрируется с SVN, или использовать его, имеет смысл использовать одно репо на проект.
Аналогично предложению Blade об обмене файлами, здесь есть несколько более простое, но менее гибкое решение. Я настраиваю наши так:
- / Var / SVN /
- / Вар / SVN / бен
- / Var / СВН / repository_files
- / Var / СВН / svnroot
- / Var / СВН / svnroot / repos1
- / Var / СВН / 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)"
Подобно тому, как 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 в этой структуре папок; а теги | филиалов | могут быть полезны для пометки настроек в различных основных версии продуктов производителя тоже).
Добро пожаловать в любые комментарии к моей структуре - я недавно изменил это на это и пока очень доволен, но иногда нахожу обременительным поддерживать структуры ветвей | тегов для проекта - особенно если проект - просто настройка проекта просто для модульного тестирования другого проекта.
Мое предложение одно. Если у вас нет разных пользователей, обращающихся к каждому, то я бы сказал, использовать несколько.
Но опять же, даже это не очень хорошая причина использовать несколько.