Общие компоненты во всех проектах есть ли лучшая альтернатива, чем svn: externals?

моя ситуация: у меня есть несколько компонентов, которые иногда имеют изменения в них, и совместно используются во многих разных проектах. Каждый проект помещает их в подпапку под названием /depends. Depends содержит кучу внешних svn для всех наших общих компонентов.

svn: внешние факторы вызывают у меня много времени и боли.

  • Show log on the project root folder не будет показывать изменения для svn: внешние папки (но достаточно смешно фиксировать и обновлять работа с svn: externals)
  • когда вы ветвитесь, svn: externals не ветвятся.
  • из-за отсутствия ветвления на svn:externals любое изменение обычно ломает ствол.
  • Теги не замораживают свои внешние данные. Это действительно разрушает цель пометки.

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

есть ли лучшая альтернатива для моей ситуации?

14
svn svn-externals

5 ответов

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

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

отметим, что svn:externals "определение" может включать в себя определенной ревизии.

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

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

12

Я согласен с @Ken.

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

одна из причин не ветвления внешних заключается в том, что неясно, как это должно быть сделано. Если ваши внешние объекты в проекте A указывают на теги / 2.0.0, и вы создаете 3.4.ветвь x для вашего проекта, на что должен указывать внешний для проекта? Следует ли также проектировать филиал? Если да, то какой версии?

Если проекты имеют разные циклы выпуска, в целом невозможно определить разумное поведение для внешних при ветвлении.

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

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

6

я заявил Это на аналогичном вопрос: Вы должны использовать svn:externals as внешний ссылки из разных репозиториев. Так что svn:externals следует ссылаться на компоненты, модули, сторонние инструменты и т. д. которые находятся в разных репозиториях.

вы должны не использовать svn:externals эмулировать"символическую ссылку" -поведение, используя внешние для указания на тот же репозиторий.

вы можете решить такие вопросы, большую часть времени изменение структуры сборки или использование скриптов проверки и разреженной функции проверки.

svn: у внешних есть много проблем, большинство из них трудно увидеть, отслеживать и ремонтировать: посмотреть пример здесь

  • коммиты не могут охватывать внешние (без атомарных коммитов)
  • ветви не будут ветвить свои внешние
  • теги не будут "замораживать" их внешние, поэтому последние сборки могут привести к различным / сломанным строит
  • слияние и reeintegrate merge не будет работать на внешних

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

5

вы можете попробовать использовать так называемые ветви поставщика:

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.vendorbr

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

2

svncopy.pl (упоминается в этот вопрос) перепишет пути в svn:externals к их новому местоположению в ветке.

0