с Subversion, как управлять версией компонента в многопроектном репозитории? - PullRequest
Новая
       61

с Subversion, как управлять версией компонента в многопроектном репозитории?

2 голосов
/ 28 октября 2011

Представьте себе организацию хранилища, подобную этой: 

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-2.0
           /trunk
/Module2/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-1.2  
           /tags/Rel-1.3
           /tags/Rel-2.0
           /tags/Rel-2.1         
           /trunk

Project1 использует Module1 и Module2. Выпуск 1.0 проекта 1 выполняется с использованием выпуска 1.0 модуля 1 и модуля 2.

Новая версия проекта 1 (названная, например, для версии 1.1, не является основной эволюцией) выполняется с использованием версии 2.0 модуля 1 и 2.1 модуля 2.

Как это сделать с помощью Subversion.

Ответы [ 2 ]

1 голос
/ 29 октября 2011

Я предложу реорганизовать репо, разделив его на отдельные репозитории для каждой «сущности» (Project, Module1, Module2, ..., ModuleN) и использую svn: externals в репозитории Project для всех модулей вместо прямого встраивания кода.

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

Pro

  • вы разделите историю удалений (в терминах SVN) на независимые части
  • для каждого помеченного выпуска связанные версии модулей легко идентифицируются
  • репозитории будут иметь более простое кодовое дерево
  • / что-то забыто /

Contra

  • история проекта не будет прозрачной из-за наличия точки бифуркации, а работа с древними ревизиями (до бифуркации) вызовет (может вызвать) некоторую головную боль
1 голос
/ 28 октября 2011

Я бы попытался решить проблему управления зависимостями вне SVN (подумайте об Apache Maven или Ivy в Javaverse).

Если это должен быть SVN, как насчет специальных имен тегов? Таким образом, вы можете ввести соглашение, согласно которому ваша система сборки просматривает специальные папки для версий, от которых она зависит, например, /Module1/branches/deps/Project1/Rel-1.0 для кода, необходимого для сборки Rel1 1.0 Project1. 

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.0
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk
/Module2/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.1         
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk

Вы можете создать папки для иждивенцев, ссылаясь на папки тегов: 

# dependencies to Module1
svn cp http://myServer/svn/Module1/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# dependencies to Module2
svn cp http://myServer/svn/Module2/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module2/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

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

# delete old reference
svn rm http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# make other one for new version
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.1 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

Недостатком этого подхода может быть увеличение места для рабочих каталогов SVN.

...