Одне сховище 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 дійсно не мають значення поза сховищем. Якщо для перегляду потрібні значущі імена, створіть TAG

Повідомлення про фіксацію легко фільтруються за допомогою шляху до сховища, тому читання лише тих, що стосуються певного проекту, є тривіальною вправою.

Редагувати: Дивіться відповідь Блейда для отримання детальної інформації про використання єдиної конфігурації авторизації / автентифікації для SVN.

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

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

Існує єдина точка для декількох сховищ: адміністрування величезних репостів незручно. Скидання / завантаження величезних репостів займає багато часу. Але оскільки ви не робите жодної адміністрації, я думаю, це не буде вас турбувати;)

SVN дуже добре масштабує масштабні сховища, навіть у великих (> 100 Гб) сховищах немає уповільнення.

Так у вас буде менше клопоту з одним сховищем. Але вам справді варто подумати про макет репо!

Я б використовував кілька сховищ. Окрім проблеми доступу з користувачем, це також спрощує резервне копіювання та відновлення. І якщо ви опинитесь у такому положенні, коли хтось хоче заплатити вам за ваш код (та його історію), простіше дати їм лише скинь у сховище.

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

Ми використовуємо єдине сховище. Моє єдине занепокоєння було масштабом, але, побачивши сховище ASF (700k редакцій та підрахунку), я був впевнений, що продуктивність не буде проблемою.

Наші проекти - це пов'язані між собою різні модулі блокування, які утворюють набір залежностей для будь-якого додатка. З цієї причини єдине сховище є ідеальним. Можливо, ви хочете окремий стовбур / гілки / теги для кожного проекту, але ви все одно можете атомним чином змінити всю вашу кодову базу в межах однієї редакції. Це приголомшливо для рефакторингу.

Майте на увазі, що приймаючи рішення, багато репонів 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 журналу), тільки це буде вагомою причиною для вибору одного сховища.

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

Якщо ви плануєте використовувати або використовувати такий інструмент, як trac, який інтегрується у SVN, має сенс використовувати одне репо за проект.

Подібно до пропозицій Блейда щодо спільного використання файлів, тут є дещо простіше, але менш гнучко рішення. Я налаштовую наші так:

• / 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", до яких усі сховища мають посилання 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 / гілки | Я використовую налаштування додатків просто як місце, щоб зберігати конкретні файли налаштувань додатків, щоб вони легко передавалися іншим (і замінювали ClientName на VendorName та ProjectName на AppName у цій структурі папок; а гілки | теги можуть бути корисними для тегування параметрів у різних основних версії продуктів постачальників теж).

Ласкаво просимо до будь-яких коментарів щодо моєї структури - я нещодавно змінив її до цього і поки що дуже задоволений, але іноді вважаю обтяжливим підтримувати структури гілок | тегів для кожного проекту - особливо, якщо проект є просто налаштуванням проекту просто для Unit Test іншого проекту.

Моя пропозиція одна. Якщо у вас різні користувачі не мають доступу до кожного, я б сказав, використовуйте кілька.

Але знову ж таки, навіть це не вагомий привід використовувати кілька.