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

Ответ 1

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

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

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

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

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

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

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

JFTR:

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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

В "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 it!
echo "Repository ${1} created. (most likely)"

Ответ 12

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

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

Ответ 13

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

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

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

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