Как вы организуете свой репозиторий для контроля версий?

Во-первых, я знаю об этом: Как бы вы организовали репозиторий Subversion для собственных программных проектов? Далее собственно вопрос: Моя команда реструктурирует наш репозиторий, и я ищу подсказки, как его организовать. (В данном случае SVN). Вот что мы придумали. У нас есть один репозиторий, несколько проектов и несколько перекрестных ссылок svn: externals

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

Чтобы очистить словарный запас: Решение означает один продукт, Project - это проект Visual Studio (в результате получается один файл .dll или один .exe).

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

Что вы думаете об этом макете? Особенно об использовании svn: externals. Это не идеальное решение, но, учитывая все плюсы и минусы, это лучшее, что мы могли придумать. Как бы ВЫ это сделали?

Вы уверены, что имеете в виду "трэш"? А точнее «хлам»?

ssc 08.02.2014 16:45
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
108
1
31 292
7

Ответы 7

Я считаю, что в Прагматический контроль версий с использованием Subversion есть все необходимое для организации вашего репозитория.

@bal Пожалуйста, не используйте службы сокращения URL-адресов. Это много, лучше сказать "Теперь это 2-е издание: Прагматический контроль версий с использованием Subversion"

meagar 25.01.2011 22:24

Мы настроили наши так, чтобы они почти точно соответствовали тому, что вы опубликовали. Используем общую форму:

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

Хотя я полагаю, что он не такой полный, как ваш пример, он хорошо сработал для нас и позволяет нам держать вещи отдельно. Мне также нравится идея, что у каждого пользователя есть папка «Thrash» - в настоящее время проекты такого типа не попадают в систему управления версиями, и я всегда чувствовал, что они должны это делать.

Я удивлен, что у вас есть отдельный каталог для документов, которые не меняются между версиями ... Я никогда не имел удовольствия работать над таким продуктом! :)

ARKBAN 20.11.2008 05:18

У меня аналогичная планировка, но мой ствол, ветки, метки полностью вверху. Итак: / trunk / main, / trunk / utils, / branch / release / и т. д.

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

Я думаю, что основным недостатком предложенной структуры является то, что общие проекты будут версироваться только с первым решением, к которому они были добавлены (если svn: externals не выглядит более привлекательным, чем я могу себе представить). Например, когда вы создаете ветвь для первого выпуска Solution2, Project1 не будет разветвлен, поскольку он находится в Solution1. Если вам потребуется выполнить сборку из этой ветки позже (выпуск QFE), он будет использовать последнюю версию Project1, а не версию Project1 на момент создания ветки.

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

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

Krzysztof Kozmic 21.10.2008 23:01

Что вы имеете в виду под «обновить ссылку, если мы хотим»? Я не понимаю, как вы могли бы разветвлять Project1 (что кажется желательным, когда вы разветвляете Solution2) без разветвления Solution1.

C. Dragon 76 22.10.2008 01:50

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

Rob Williams 20.11.2008 04:12

Почему все это в одном репозитории? Почему бы просто не создать отдельный репозиторий для каждого проекта (я имею в виду «Решение»)?

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

А сколько проектов вы планируете поместить в один большой репозиторий? 2? 3? 10? 100?

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

А как насчет беспорядка со всеми этими номерами версий? Номера версий одного проекта выглядят как 2, 10, 11, а другого - как 1, 3, 4, 5, 6, 7, 8, 9, 12 ...

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

1. Один репозиторий - это политика компании, это изменить нельзя. 2. У нас будет около десятка решений. 3. под номерами версий вы подразумеваете ревизии? Для нас это не проблема.

Krzysztof Kozmic 21.10.2008 23:04

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

Rob Williams 20.11.2008 04:13

Обратите внимание, что наличие нескольких репозиториев во многих (большинстве?) Инструментов управления версиями может быть ОЧЕНЬ дорого, например, при реализации безопасности.

Rob Williams 20.11.2008 04:16

Чтобы добавить к проблеме относительного пути:

Не уверен, что это проблема:
Просто проверьте Solution1 / trunk в каталоге с именем «Solution1», то же самое для Solution2: цель «каталогов», фактически представляющих ветки, состоит в том, чтобы не быть видимым был импортирован в рабочую область. Следовательно, возможны относительные пути между «Solution1» (фактически «Solution1 / trunk») и «Solution2» (Solution2 / trunk).

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

Rob Williams 20.11.2008 04:16

RE: относительный путь и проблема с общим файлом -

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

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

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

Rob Williams 20.11.2008 04:18

Другие вопросы по теме