Общие компоненты во всех проектах, есть ли лучшая альтернатива, чем svn:externals?
Моя ситуация: у меня есть несколько компонентов, в которые иногда вносятся изменения, и которые используются в разных проектах. Каждый проект помещает их в подпапку, которая называется / зависит. Зависимость содержит кучу внешних SVN для всех наших общих компонентов.
svn:externals причиняет мне много времени и боли.
- Показать журнал в корневой папке проекта не будет отображать изменения для папок svn: external (но достаточно забавный коммит и обновление будут работать с svn:externals)
- При ветвлении svn:externals не разветвляется.
- Из-за отсутствия ветвления в svn:externals, любое изменение обычно ломает ствол.
- Теги не замораживают свои внешние. Это действительно побеждает цель пометки.
Помните, что у меня есть несколько проектов (скажем, 10 для этого обсуждения, каждый из которых использует одни и те же внешние элементы), поэтому сохранение нормальных выделенных каталогов для каждого проекта стоило бы мне много времени на слияние.
Есть ли лучшая альтернатива для моей ситуации?
5 ответов
Я считаю, что часть проблемы заключается в том, что циклы выпуска для общих компонентов не обязательно совпадают с циклами выпуска для проектов.
Общие компоненты, как описано здесь, имеют свой собственный цикл выпуска. Другими словами, каждый из них может управляться как отдельный проект (или, возможно, их коллекция управляется как отдельный проект) с собственным номером версии / выпуска.
Обратите внимание, что svn:externals определение может включать конкретную ревизию.
Это позволяет разрабатывать каждый из проектов, использующих общий компонент, для конкретного выпуска / ревизии этого общего компонента (или набора общих компонентов), обеспечивая стабильный набор зависимостей для проекта. Изменения в компонентах не повредят проектам, потому что каждый проект рассматривает конкретную версию компонентов, которая не обязательно HEAD на trunk,
Хотя это может показаться более сложной задачей, я считаю, что в долгосрочной перспективе эта практика обеспечит лучший процесс управления изменениями для ситуаций такого типа.
Я согласен с @Ken.
Я очень настоятельно рекомендую не использовать svn:externals вообще без конкретной ревизии. Без пересмотра невозможно воссоздать старые кассы. Если вы помечаете свои внешние элементы только при пометке, вы сможете воссоздать только то, что отметили. Если вы хотите воссоздать некоторую промежуточную ревизию в транке, вы по своему усмотрению.
Одна из причин не разветвления внешних факторов заключается в том, что неясно, как это должно быть сделано. Если ваши внешние элементы в проекте A указывают на теги /2.0.0, и вы создаете ветку 3.4.x для своего проекта, на что должен указывать внешний элемент для проекта A? Должен ли проект А также быть филиалом? Если да, то к какой версии?
Если проекты имеют разные циклы выпуска, в общем случае невозможно определить разумное поведение для внешних элементов при ветвлении.
(Возможно, вы захотите взглянуть на svncopy.pl сценарий, если вы еще этого не сделали (включен в дистрибутив исходного кода Subversion), который позволяет закреплять внешние элементы во время тегирования.)
Мы обнаружили, что svn:externals работает очень плохо, когда используется для объединения набора компонентов, которые вы активно разрабатываете. Externals хорошо работает, чтобы добавить внешние компоненты, которые не сильно перемещаются, и где у вас нет проблемы ветвления.
Я изложил это по аналогичному вопросу: вы должны использовать svn:externals как внешние ссылки из разных репозиториев. Так svn:externals должны ссылаться на компоненты, модули, сторонние инструменты и т. д., которые находятся в разных репозиториях.
Вы не должны использовать svn:externals подражать поведению "символической ссылки", используя внешние ссылки для указания на тот же репозиторий.
Вы можете решить такие проблемы большую часть времени, изменив свою структуру сборки, или используя checkout-скрипты и функцию разреженного извлечения.
svn: внешние проблемы имеют много проблем, большинство из которых трудно увидеть, отследить и исправить: посмотрите пример здесь
- коммиты не могут охватывать внешние (без атомарных коммитов)
- ветви не будут разветвляться
- теги не "замораживают" свои внешние компоненты, поэтому последние сборки могут привести к различным / неработающим сборкам
- слияние и реинтеграция слияния не будут работать на внешних
Если вы используете внешние ссылки для указания на другие репозитории, в большинстве случаев у вас не будет этих проблем.
Вы можете попробовать использовать так называемые ветки вендоров:
http://svnbook.red-bean.com/en/1.5/svn-book.html
Это полезная стратегия, когда вы имеете дело со сторонними библиотеками, но она также может быть полезна в такой ситуации, как ваша.
svncopy.pl (упомянутый в этом вопросе) перепишет пути в svn:externals на их новое место в филиале.