Обработка отношений между несколькими проектами подрывной деятельности

Question

В моей компании мы используем один репозиторий SVN для хранения нашего кода на C++. База кода состоит из общей части (инфраструктуры и приложений) и клиентских проектов (разработанных как плагины).

Компоновка хранилище выглядит следующим образом:

• Инфраструктура
• app1
• App2
• app3
• проектов для-клиент-1
  • App1-плагин
  • App2-plugin
  • Конфигурация
• проект-для-клиент-2
  • App1-плагин
  • App2-плагин
  • Конфигурация

Типичный выпуск для клиента проект включает данные проекта и каждый использованный проект (например, Инфраструктура).

Фактическое расположение каждой директории -

• Инфраструктура
  • ветви
  • теги
  • ствол
• проект-для-клиент-2
  • ветви
  • теги
  • ствол

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

У нас есть несколько проблем с макетом выше:

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

Есть ли способ в SVN решить любой из вышеперечисленных? Я думал об использовании svn: externals в клиентских проектах, но после прочтения this post Я понимаю, что это может быть неправильный выбор.

Answer 1

Вы можете справиться с этим с помощью svn: externals.Это URL-адрес места в svn repo Это позволяет вам тянуть части другого репозитория (или того же самого). Один из способов использования этого - в проекте-для-клиента2, вы добавляете ссылку svn: externals в ветку инфраструктуры, в которой вы нуждаетесь, ветку приложения 1, которая вам нужна, и т. Д. Поэтому, когда вы проверяете проект для клиента2, вы получаете все правильные фигуры.

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

Answer 2

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

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

Answer 3

Да, это отстой. Мы делаем то же самое, но я не могу думать о лучшей компоновке.

Итак, у нас есть набор скриптов, которые могут автоматизировать все связанные с subversion. Проект каждого клиента будет содержать файл с именем project.list, который содержит все проекты/пути подрывной деятельности, необходимые для сборки этого клиента. Например:

Infrastructure/trunk 
LibraryA/trunk 
LibraryB/branches/foo 
CustomerC/trunk 

Каждый сценарий, то выглядит примерно так:

for PROJ in $(cat project.list); do 
    # execute commands here 
done 

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

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

Answer 4

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

• инфраструктуры
  • ветви
  • теги
  • ствол
• проект-для-клиент-1
  • ветви
  • теги
  • ствол
• проект-для-клиент-2
  • ветви
  • теги
  • ствола

к

• ветви
  • функция-1
    • Инфраструктура
    • проект-для-клиент-1
    • проект-для-клиент-2
• тегов
• ствола
  • Инфраструктура
  • проекта-для-клиент-1
  • проект-для-клиент-2

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

Чтобы работать с кодом, можно просто проверить багажник и работать с ним. Тогда вам не нужны сценарии, которые проверяют все разные проекты. Они просто ссылаются на инфраструктуру с «../Infrastructure». Другая проблема с этим макетом заключается в том, что вам нужно проверить несколько копий, если вы хотите полностью работать над проектами. В противном случае изменение инфраструктуры для одного проекта может привести к тому, что другой проект не будет компилироваться до тех пор, пока он не будет обновлен.

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

Answer 5

Во-первых, я не согласитесь, что внешние являются злыми. Хотя они не идеальны.

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

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

Внешние ссылки не являются панацеей, и, как видно из сообщений, могут быть проблемы. Я уверен, что есть что-то лучше, чем внешние, но я еще не нашел его (даже концептуально). Разумеется, структура, которую вы используете, может дать большую информацию и контроль в вашем процессе разработки, используя внешние ресурсы. Тем не менее, проблемы, которые у него были, были не фундаментальными проблемами коррупции - чистый get разрешил все и довольно редко (вы действительно не можете создать новую ветвь библиотеки в своем репо?).

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

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