Обработка отношений между несколькими проектами Subversion - PullRequest
4 голосов
/ 10 сентября 2009

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

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

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

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

Фактический макет каждого каталога -

  • Инфраструктура
    • метка
    • багажник
  • проект-для-клиент-2
    • ветви * +1052 *
    • метка
    • багажник

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

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

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

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

Ответы [ 5 ]

3 голосов
/ 10 сентября 2009

Вы можете справиться с этим с помощью svn: externals. Это ссылка на место в SVN репо Это позволяет вам извлекать части другого хранилища (или того же самого). Один из способов использовать это в разделе project-for-client2: вы добавляете ссылку svn: externals в нужную вам ветвь инфраструктуры, нужную ветвь app1 и т. Д. все правильные кусочки.

Ссылки svn: externals версионированы вместе со всем остальным, так что когда проект для клиента1 будет помечен, разветвлен и обновлен, правильные внешние ветви всегда будут извлечены.

2 голосов
/ 10 сентября 2009

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

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

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

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

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

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

2 голосов
/ 10 сентября 2009

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

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

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

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

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

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

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

2 голосов
/ 10 сентября 2009

Рекомендуется изменить макет каталога с

  • Инфраструктура
    • филиалы
    • метка
    • багажник
  • проект-для-клиент-1
    • ветви * * 1016
    • метка
    • багажник
  • проект-для-клиент-2
  • метка
  • багажник

до

  • филиалы
    • особенность-1
      • Инфраструктура
      • проект-для-клиент-1
      • проект-для-клиент-2
  • метка
  • Ствол
    • Инфраструктура
    • проект-для-клиент-1
    • проект-для-клиент-2

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

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

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

0 голосов
/ 10 сентября 2009

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

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

...