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

Question

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

должны ли мы иметь один репозиторий для всей компании, который содержит много проектов развития, или репозиторий для каждого проекта? Любые идеи по опыту / передовой практике?

12 52

svn repository

12 ответов:

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

прозрачность: так легче следить за тем, что происходит, и найти код, даже в проекты, в которых вы не можете принимать непосредственное участие.

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

техническое обслуживание: необходимо только создать резервную копию одного репозитория.

EDIT: Дополнительные причины:

глобальные идентификаторы ревизий-имея идентификаторы ревизий быть глобальными это:

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

легче гарантию атомарность когда проекты имеют зависимости друг от друга.

на порядок коммитов для разных проектов.

39

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

вы заметите, что все примеры в svn book предположим, что все находится в одном репозитории.

есть отдельный вопрос о том, чтобы использовать /багажник/проект1, /багажник/проект2 /филиалы/проект1-R1 или использовать /проект1/ствола, /проект1/филиалы/Р1 /проект2/багажник. Как правило, второй легче отслеживать.

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

svn / code для всей разработки программного обеспечения, требует Jira билет для фиксации

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

16

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

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

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

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

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

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

8

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

3

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

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

минусы:

ветвление может быть трудно, так как многие папки и файлы могут быть вовлечены

хранилище может стать огромным

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

немного меньше контроля архитектуры проекта (см. Плюсы)

плюсы:

все проекты имеют одинаковую историю репозитория

ветвление для всего репозитория

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

лучший обзор и мониторинг параметров репозитория коммиты

ИМХО (и в отношении нашего конкретного проекта) плюсы перевешивают минусы.

3

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

Так это будет выглядеть так
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Project1 может обращаться к интерфейсному коду и содержит подпроекты, такие как admin/ и web/ Project2 будет backend и содержит различные инструменты и приложения для мониторинга

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

1

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

для команд, работающих над несколькими меньшими проектами одновременно, один репозиторий обеспечивает простой механизм для управления всем в одном месте (резервное копирование, поиск и т. д.). Центральное РЕПО также делает сам репозиторий похожим немного больше "бетона", так как он не будет отброшен, как только проект будет завершен или заброшен.

1

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

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

1

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

0

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

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

0

Я работаю в компании, которая работает для многих клиентов со строгими правилами. На данный момент у нас около 130 разработчиков. У нас есть основной проект, который настроен на потребности каждого клиента. И у нас есть один огромный репозиторий SVN. Это будет заноза в заднице, если бы нам пришлось проверить всю ветку, но наша стратегия заключается в том, чтобы переместить проекты из общей ветки и оставить только для команд переключения. :) Таким образом, все может быть сохранено в одном хранилище.

моей единственной заботой было разделение репозитория на несколько репозиториев, если это необходимо в случае аутсорсинга части работы или продажи всего проекта, пока я не нашел это: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories

поэтому я думаю, что SVN switch облегчает боль длительной проверки (один переключает только нужные проекты), но у нас может быть один репозиторий. Но, если все еще нужно, можно извлечь набор компоненты для разделения репозитория.

0

altern · Accepted Answer · 2009-11-19 11:55:19

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

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

размер репозитория. Насколько велик ваш проект? Есть ли у него двоичные файлы под управлением исходного кода? Держу пари, что так и есть. Поэтому важен размер-каждая ревизия двоичного файла увеличивает размер репозитория. В конце концов он становится неуклюжим, и его трудно поддерживать. Должна поддерживаться мелкозернистая политика хранения двоичных файлов и предоставляться дополнительное администрирование. Что касается меня, я все еще не могу найти как я могу полностью удалить двоичный файл (совершенных какой-то глупый пользователь) и его история содержимого из репозитория. С репозиторием для каждого проекта было бы проще.
внутренняя организация репозитория. Я предпочитаю мелкозернистые, очень организованные, автономные, структурированные репозитории. Там есть - схемы иллюстрирующий общий (идеальный) подход к процессу обслуживания репозитория. Я думаю, вы согласитесь, что просто невозможно использовать подход "все проекты в одном РЕПО". Например, мой начальная структура репозитория (каждый репозиторий проекта должен иметь):
/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases
администрирование РЕПО. "Репозиторий для каждого проекта" имеет больше возможностей в конфигурации доступа пользователей. Однако это более сложно. Но есть и полезная функция: вы можете настроить репозитории для использования одного и того же файла конфигурации

Поддержка РЕПО. Я предпочитаю резервное копирование репозиториев отдельно. Кто-то говорит, что в этом случае невозможно объединить информацию из одного РЕПО в другое. С какой стати тебе это нужно? Случай, когда требуется такое слияние, показывает, что первоначальный подход к управлению версиями неверен. Развитие проекта предполагает последующее разделение проекта на подпроекты, а не наоборот. И я знаю, что есть подход, чтобы сделать это.

svn: externals. Подход "репозиторий на проект" поощряет использование svn:externals. То есть здоровый ситуация, когда зависимости между проектом и подмодулями устанавливаются через мягкие ссылки, каковым является svn:externals.

вывод. Если вы хотите сохранить управление версиями простым, используйте один репозитория. Если вы хотите сделать правильное управление конфигурацией программного обеспечения:

использовать 'в проекте' подход

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

наймите хорошего администратора, который сможет справиться со всеми диверсионными трюками:)
PS. Кстати, несмотря на то, что я постоянно работаю с SVN и мне это нравится, подход "репозиторий на проект" - это то, почему я вижу системы DCVS более привлекательными с точки зрения организации репозитория. В DCVS РЕПО-это проект по умолчанию. Там даже нет вопроса "один против нескольких" возможно, это было бы просто нонсенс.