Обработка связей между несколькими проектами subversion
-
05-07-2019 - |
Вопрос
В моей компании мы используем один репозиторий SVN для хранения нашего кода на C ++.Кодовая база состоит из общей части (инфраструктура и приложения) и клиентских проектов (разработанных в виде плагинов).
Макет репозитория выглядит следующим образом:
- Инфраструктура
- Приложение 1
- Приложение 2
- Приложение 3
- проект-для-клиента-1
- App1-плагин
- App2-плагин
- Конфигурация
- проект-для-клиента-2
- App1-плагин
- App2-плагин
- Конфигурация
Типичный выпуск для клиентского проекта включает данные проекта и каждый проект, который им используется (напримерИнфраструктура).
Фактический макет каждого каталога выглядит следующим образом -
- Инфраструктура
- ветви
- Теги
- багажник
- проект-для-клиента-2
- ветви
- Теги
- багажник
И то же самое касается остальных проектов.
У нас есть несколько проблем с описанным выше макетом:
- Сложно запустить новую среду разработки для клиентского проекта, поскольку необходимо проверить все задействованные проекты (например:Инфраструктура, Приложение 1, приложение 2, проект для клиента-1).
- Трудно пометить релиз в клиентских проектах по той же причине, что и выше.
- В случае, если клиентскому проекту необходимо изменить какой-то общий код (напримерИнфраструктура), мы иногда используем филиал.Трудно отследить, какие ветви используются в проектах.
Есть ли в SVN какой-либо способ решить что-либо из вышеперечисленного?Я думал об использовании svn: externals в клиентских проектах, но после прочтения этот пост Я понимаю, что это может быть неправильный выбор.
Решение
Вы могли бы справиться с этим с помощью svn: externals .Это URL-адрес места в репозитории svn Это позволяет вам извлекать части из другого репозитория (или того же самого).Один из способов использовать это - в project-for-client2 вы добавляете ссылку svn: externals на нужную вам ветку инфраструктуры, нужную вам ветку app1 и т.д.Итак, когда вы проверяете project-for-client2, вы получаете все правильные фрагменты.
Ссылки svn: externals версифицируются вместе со всем остальным, поэтому, когда project-for-client1 помечается, разветвляется и обновляется, всегда будут подключены правильные внешние ветви.
Другие советы
Предложение состоит в том, чтобы изменить макет каталога с
- Инфраструктура
- ветви
- Теги
- багажник
- проект-для-клиента-1
- ветви
- Теги
- багажник
- проект-для-клиента-2
- ветви
- Теги
- багажник
Для
- ветви
- особенность-1
- Инфраструктура
- проект-для-клиента-1
- проект-для-клиента-2
- особенность-1
- Теги
- багажник
- Инфраструктура
- проект-для-клиента-1
- проект-для-клиента-2
С этим макетом тоже есть некоторые проблемы.Ветви становятся массивными, но, по крайней мере, становится проще помечать определенные места в вашем коде.
Чтобы работать с кодом, можно было бы просто проверить магистраль и поработать с этим.Тогда вам не нужны скрипты, которые проверяют все различные проекты.Они просто ссылаются на Инфраструктуру с помощью "../Infrastructure".Другая проблема с этим макетом заключается в том, что вам нужно оформить несколько копий, если вы хотите работать над проектами полностью независимо.В противном случае изменение инфраструктуры для одного проекта может привести к тому, что другой проект не будет компилироваться до тех пор, пока он тоже не будет обновлен.
Это также может сделать релизы немного более громоздкими и разделить код для разных проектов.
Да, это отстой.Мы делаем то же самое, но я действительно не могу придумать лучшего макета.
Итак, что у нас есть, так это набор скриптов, которые могут автоматизировать все, что связано с subversion.Проект каждого клиента будет содержать файл под названием project.list
, который содержит все проекты / пути subversion, необходимые для создания этого клиента.Например:
Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk
Затем каждый скрипт выглядит примерно так:
for PROJ in $(cat project.list); do
# execute commands here
done
Где командами могут быть проверка, обновление или тег.Это немного сложнее, чем это, но это означает, что все согласовано, проверка, обновление и пометка становятся единой командой.
И, конечно, мы стараемся как можно меньше разветвляться, что является самым важным предложением, которое я могу сделать.Если нам нужно что-то разветвлять, мы попытаемся либо отработать магистральную версию, либо ранее помеченную версию как можно большего числа зависимостей.
Во-первых, я не согласен с тем, что внешнее - это зло.Хотя они и не идеальны.
В данный момент вы выполняете несколько проверок для создания рабочей копии.Если бы вы использовали externals, он делал бы именно это, но каждый раз автоматически и последовательно.
Если вы указываете своим внешним элементам теги (и / или конкретные ревизии) в целевых проектах, вам нужно пометить только текущий проект для каждого выпуска (поскольку этот тег будет точно указывать, на какой внешний элемент вы указывали).У вас также была бы запись в вашем проекте о том, когда именно вы изменили свои внешние ссылки, чтобы использовать новую версию определенной библиотеки.
Внешние средства не являются панацеей - и, как показывает сообщение, могут возникнуть проблемы.Я уверен, что есть что-то лучше, чем externals, но я еще не нашел этого (даже концептуально).Конечно, структура, которую вы используете, может предоставить большой объем информации и контроля в вашем процессе разработки, а использование внешних ресурсов может дополнить это.Однако проблемы, с которыми он столкнулся, не были фундаментальными проблемами коррупции - чистое получение решило бы все и встречается довольно редко (вы действительно не можете создать новую ветвь библиотеки в своем репозитории?).
Моменты для рассмотрения - использование рекурсивных внешних элементов.Я не уверен ни в "да", ни в "нет" по этому поводу и склоняюсь к прагматичному подходу.
Рассмотрите возможность использования piston, как предлагается в статье, я не видел его в действии, поэтому не могу комментировать, он может выполнять ту же работу, что и внешние устройства, но лучше.
Исходя из моего опыта, я думаю, что более полезно иметь репозиторий для каждого отдельного проекта.В противном случае у вас возникнут проблемы, о которых вы говорите, и, кроме того, номера редакций изменятся, если изменятся другие проекты, что может привести к путанице.
Только тогда, когда существует связь между отдельными проектами, такими как программное обеспечение, аппаратные схемы, документация и т.д.Мы используем единый репозиторий, поэтому номер редакции служит для приведения всего пакета в известное состояние.