Несколько репозиториев SVN или единственного репозитория компании

Я настоятельно рекомендую не использовать репозиторий для каждого проекта. В одном репозитории Subversion вы можете перемещать и копировать данные, и они сохранят свою историю. Если вы решите, что какой-то фрагмент кода, запущенный как серверный инструмент, объединяется с внешним интерфейсом, и они находятся в разных репозиториях, это не та операция, о которой Subversion будет знать что-либо. Будет так, как будто вы добавили что-то в фронтенд ниоткуда. Это также означает, что вы не можете выполнять слияние, если вам необходимо временно поддерживать две версии связанного кода.

Вы заметите, что все примеры в svn book предполагают, что все находится в одном репозитории. 12157] Существует отдельный вопрос, использовать ли / trunk / project1, / trunk / project2, / branch / project1-r1 или использовать / project1 / trunk, / project1 / branch / r1, / проект2 / ствол. Как правило, за вторым легче следить.

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

• svn / code для разработки всего программного обеспечения, требуется билет jira для фиксации
• svn / ops для любой конфигурации, сценариев установки, сторонних файлов tars и т.д., jira не требуется

Это будет зависеть от того, насколько взаимозависимы ваши приложения / проекты в организации, а также от того, насколько велики кодовые базы. Таким образом, все сводится к тому, как определять «проект» в вашей организации. Общая кодовая база, общие компоненты, общие команды, общие циклы выпуска - все это может повлиять на то, как ваши репозитории должны быть структурированы.

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

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

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

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

При этом, если все проекты небольшие по размеру,

Пока очень хорошие, содержательные ответы, но я просто хочу добавить свои два цента:

Я думаю, это зависит от размера вашего проекта. Мы попробовали оба подхода, но в конце концов остановились на одном большом репозитории.

Минусы :

• Ветвление может быть трудным, так как может быть задействовано много папок и файлов
• Репозиторий может стать ОГРОМНЫМ
• Вы необходимо проверить весь репозиторий (или, по крайней мере, отдельные ветви), чтобы построить свое решение
• Немного меньше контроля над архитектурой проекта (см. плюсы)

Плюсы :

Если вы используете Subversion, у вас может быть несколько репозиториев в одном домене с несколькими проектами в каждом.

Таким образом, это выглядит так, как

Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2

Project1 может адресовать внешний код и содержать под -проекты, такие как admin / и web / Project2 будет бэкэнд и будет содержать различные инструменты и приложения для мониторинга

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

Я обнаружил, что наличие одного репозитория Subversion помогает в:

1. Прозрачности : легче следить за тем, что есть происходит, и найти код даже в проекты, в которых вы, возможно, не принимаете непосредственного участия.
2. Обслуживание : нет необходимости создавать репозитории каждый раз, когда вы хотите создайте новый проект, и вы сможете удалить проекты целиком, не боясь потерять запись из Subversion.
3. Техническое обслуживание : необходимо создать резервную копию только одного репозитория.

РЕДАКТИРОВАТЬ: Дополнительные причины:

• Глобальные идентификаторы ревизий - если идентификаторы ревизий являются глобальными, это:
  1. Легче сообщить (например, в запросе на проверку кода просто укажите версию id, без необходимости указывать, какой проект).
  2. Проще гарантировать атомарность , когда проекты зависят друг от друга.
  3. Легче увидеть порядок коммитов для разных проекты.

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

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

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

В зависимости от того, какой тип работы выполняет ваша организация, другой вариант - иметь по одному репозиторию на каждый клиент . Там, где я работаю, в настоящее время у нас есть четыре репозитория - один для проектов, которые являются полностью внутренними для нас, один для программного обеспечения, которое мы продаем, и два, которые полностью относятся к конкретным клиентам, для которых мы производим индивидуальное программное обеспечение, применимое только к ним. Это попытка решения «лучшего из обоих миров» - у нас нет одного массивного репозитория, который содержит все и имеет номер редакции в миллиарды (я, очевидно, преувеличиваю!), Но и у нас нет десятков ничтожно маленьких репозиториев. валяется с одним проектом в каждом.

У меня был бы репозиторий для проекта, просто для того, чтобы номера ревизий были для каждого проекта. Вы можете настроить обслуживание SVN таким образом, чтобы ко всем проектам можно было получить доступ из одной точки доступа с использованием Apache и DAV SVN (с директивой SVNParentPath).

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

Я сделал и то, и другое, и в обоих случаях мне иногда жаль, что я выбрал другой метод ...

Я остановился на одном репозитории. хорошее решение. Обратите внимание, что если бы я работал в более крупной компании, я бы пересмотрел свое решение.