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

Question

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

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

• Показать журнал в корневой папке проекта не покажет изменения для папок svn: external (но достаточно забавные коммит и обновление будут работать с svn: externals)
• Когда вы разветвляетесь, svn: externals не разветвляются.
• Из-за отсутствия ветвления в svn: externals, любое изменение обычно ломает ствол.
• Теги не замораживают свои внешние. Это действительно побеждает цель пометки.

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

Я говорил об этом на похожем вопросе : Вы должны использовать svn:externals в качестве внешних ссылок из разных репозиториев. Поэтому svn:externals должно относиться к компонентам, модулям, сторонним инструментам и т. Д., Которые находятся в разных репозиториях.

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

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

svn: внешние проблемы имеют множество проблем, большинство из которых трудно увидеть, отследить и исправить: см. Пример здесь

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

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

Answer 4

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

http://svnbook.red -bean.com / о / 1,5 / СВН-book.html # svn.advanced.vendorbr

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

Answer 5

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