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