Что делать с несколькими проектами в зависимости от одного источника?

Question

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

Я на самом деле использую SVN для всего этого, но, похоже, это должно быть общей проблемой управления версиями.

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

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

Ex:

Проект № 1 должен использовать класс MyExampleClass, однако MyExampleClass - это то, что определено как часть и необходимо для Project # 2.

Answer 1

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

root
+---common
|   +---lib1
|   |   \---trunk
|   |       +---include
|   |       \---src
|   \---lib2
|       \---trunk
|           +---include
|           \---src
+---proj1
|   \---trunk
|       +---include
|       |   \---common
|       \---src
|           \---common
\---proj2
    \---trunk
        +---include
        |   \---common
        \---src
            \---common

Каталоги common в include и src в проекте содержат внешние определения, которые используются в общих библиотеках:

c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
  svn:externals : lib1 http://.../common/lib1/trunk/src
                  lib2 http://.../common/lib2/trunk/src

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

1. Это относится к динамической цели - trunk.
2. Это не относится к явной ревизии.

Когда вы выполняете ветвление, используя svn copy, внешние элементы копируются дословно, поскольку они на самом деле являются просто свойствами, прикрепленными к объекту. Некоторые другие команды svn (commit, checkout и export) фактически интерпретируют свойства. Когда вы помечаете проект, вы действительно хотите сохранить его состояние на все времена. Это означает, что вам нужно «прикрепить» внешние элементы к определенной ревизии, поэтому вам нужно изменить определение внешних элементов, чтобы они явно ссылались на нужную версию (например, "lib1 -r42 http://.../common/lib1/trunk/src"). Это решает один аспект проблемы.

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

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

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

Answer 2

Просмотр svn:externals

Answer 3

Внешние, но помните об этой проблеме:

Обновление Subversion до даты

Answer 4

Поместите все общие файлы в отдельную папку либо в один из проектов, либо в отдельный. Затем используйте externals для ссылки на эту папку. Смешивать файлы из разных мест в одной папке - плохая идея.

Answer 5

svn: externals позволит вам вводить файлы на уровне каталогов. Как:

Proj1\
  File1
  File2

Proj2\
  File3
  File4

Тогда в Proj2 вы можете использовать svn: externals Proj1 и получить:

Proj2\
  Proj1\
    File1
    File2
  File3
  File4

Теперь, если вы хотите иметь файлы из 2 проектов в 1 папке, например:

Proj2\
  File1 <- from Proj1
  File2 <- from Proj1
  File3
  File4

Тогда я не думаю, что SVN поддерживает это.

Однако я работал с другими инструментами контроля версий, которые позволили бы вам «связать» один файл из одного проекта с другим в любом месте, в котором вы хотите (в частности, Borland StarTeam).