Подтвердить что ты не робот

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

Лично я определенно предпочел бы отдельный репозиторий для каждого проекта. Существует несколько причин:

  • Номера версий. Каждый репозиторий проекта будет иметь отдельную последовательность изменений.

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

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

  • Организация внутреннего репозитория. Я предпочитаю мелкозернистые, очень организованные, самодостаточные, структурированные репозитории. Существует диаграмма иллюстрирующая общий (идеальный) подход к процессу обслуживания репозитория. Я думаю, вы согласитесь, что просто НЕ МОЖЕТ использовать "все проекты в одном репо" . Например, моя первоначальная структура репозитория (каждый репозиторий проекта должна иметь):

    /project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

  • Администрирование репо. "Репозиторий для каждого проекта" имеет больше возможностей в настройке доступа пользователей. Однако это сложнее. Но есть также полезная функция: вы можете настроить репозитории на использование одного и того же файла конфигурации

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

  • SVN: внешние. Подход "Репозиторий на один проект" поощряет использование svn: externals. Это здоровая ситуация, когда зависимости между проектом и подмодулями устанавливаются через soft links, что svn: externals.

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

    • Использовать подход "репозиторий для каждого проекта"
    • Ввести отдельную роль диспетчера конфигурации программного обеспечения и присвоить ему член команды.
    • Нанять хорошего администратора, который может справиться со всеми трюками subversion:)

PS. Кстати, несмотря на то, что я все время работаю с SVN, и мне это нравится, подход "репозиторий для каждого проекта" - вот почему я вижу, что системы DCVS более привлекательны с точки зрения организации репозитория. В DCVS репо является проектом по умолчанию. Существует даже вопрос "один против нескольких", это было бы просто вздор.

Ответ 2

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

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

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

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

Ответ 3

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

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

Существует отдельный вопрос: использовать /trunk/project 1,/trunk/project2,/branches/project1-r1 или использовать /project 1/trunk,/project1/branches/r1,/project2/trunk. Как правило, второй легче отслеживать.

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

против

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

Pros

  • Все проекты используют одну и ту же историю репозитория
  • Ветвление для всего репозитория
  • Гораздо меньше администрирования (отдельные разработчики могут создавать новые проекты без помощи sysadmin)
  • Улучшены параметры обзора и мониторинга репозитория.

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

Ответ 7

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

Итак, это будет выглядеть как

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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

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