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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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